fix typos
gbzhu
parent
da5c6e41c2
commit
2cc0485a70
|
|
@ -6,7 +6,7 @@ You can click the **Fork** button in the upper-right area of the screen to creat
|
|||
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* [Contributing to the kubernetes Documentation](http://kubernetes.io/editdocs/)
|
||||
* [Contributing to the Kubernetes Documentation](http://kubernetes.io/editdocs/)
|
||||
* [Creating a Documentation Pull Request](http://kubernetes.io/docs/contribute/create-pull-request/)
|
||||
* [Writing a New Topic](http://kubernetes.io/docs/contribute/write-new-topic/)
|
||||
* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/stage-documentation-changes/)
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ For the purposes of these flags, _legacy_ APIs are those APIs which have been ex
|
|||
|
||||
The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
|
||||
When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable
|
||||
by the kubernetes API server.
|
||||
by the Kubernetes API server.
|
||||
|
||||
`KUBE_API_VERSIONS` environment variable for the `kube-apiserver` binary which controls the API versions that are supported in the cluster. The first version in the list is used as the cluster's storage version. Hence, to set a specific version as the storage version, bring it to the front of list of versions in the value of `KUBE_API_VERSIONS`. You need to restart the `kube-apiserver` binary
|
||||
for changes to this variable to take effect.
|
||||
|
|
|
|||
|
|
@ -218,7 +218,7 @@ Once you've registered your cluster with the federation, you'll need to update K
|
|||
|
||||
### Kubernetes 1.5+: Passing federations flag via config map to kube-dns
|
||||
|
||||
For kubernetes clusters of version 1.5+, you can pass the
|
||||
For Kubernetes clusters of version 1.5+, you can pass the
|
||||
`--federations` flag to kube-dns via the kube-dns config map.
|
||||
The flag uses the following format:
|
||||
|
||||
|
|
@ -352,7 +352,7 @@ $ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google-clouddns FEDERATION_NAM
|
|||
set appropriately if it is missing and `KUBERNETES_PROVIDER` is one of `gce`, `gke` and `aws`.
|
||||
This is used to resolve DNS requests for federation services. The service
|
||||
controller keeps DNS records with the provider updated as services/pods are
|
||||
updated in underlying kubernetes clusters.
|
||||
updated in underlying Kubernetes clusters.
|
||||
|
||||
`FEDERATION_NAME` is a name you can choose for your federation. This is the name that will appear in DNS routes.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ External garbage collection tools are not recommended as these tools can potenti
|
|||
|
||||
### Image Collection
|
||||
|
||||
kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
Kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
of cadvisor.
|
||||
|
||||
The policy for garbage collecting images takes two factors into consideration:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ It assumes some familiarity with concepts in the [User Guide](/docs/user-guide/)
|
|||
|
||||
## Planning a cluster
|
||||
|
||||
There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this
|
||||
There are many different examples of how to setup a Kubernetes cluster. Many of them are listed in this
|
||||
[matrix](/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*.
|
||||
|
||||
Before choosing a particular guide, here are some things to consider:
|
||||
|
|
@ -25,12 +25,12 @@ Before choosing a particular guide, here are some things to consider:
|
|||
- Will your cluster be on-premises, or in the cloud (IaaS)? Kubernetes does not directly support hybrid clusters. We
|
||||
recommend setting up multiple clusters rather than spanning distant locations.
|
||||
- Will you be running Kubernetes on "bare metal" or virtual machines? Kubernetes supports both, via different distros.
|
||||
- Do you just want to run a cluster, or do you expect to do active development of kubernetes project code? If the
|
||||
- Do you just want to run a cluster, or do you expect to do active development of Kubernetes project code? If the
|
||||
latter, it is better to pick a distro actively used by other developers. Some distros only use binary releases, but
|
||||
offer is a greater variety of choices.
|
||||
- Not all distros are maintained as actively. Prefer ones which are listed as tested on a more recent version of
|
||||
Kubernetes.
|
||||
- If you are configuring kubernetes on-premises, you will need to consider what [networking
|
||||
- If you are configuring Kubernetes on-premises, you will need to consider what [networking
|
||||
model](/docs/admin/networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](/docs/admin/multi-cluster).
|
||||
- You may want to familiarize yourself with the various
|
||||
|
|
|
|||
|
|
@ -62,9 +62,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
|||
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
|
||||
--horizontal-pod-autoscaler-sync-period duration The period for syncing the number of pods in horizontal pod autoscaler. (default 30s)
|
||||
--insecure-experimental-approve-all-kubelet-csrs-for-group string The group for which the controller-manager will auto approve all CSRs for kubelet client certificates.
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 30)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 30)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 20)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 20)
|
||||
--kubeconfig string Path to kubeconfig file with authorization and master location information.
|
||||
--large-cluster-size-threshold int32 Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller. (default 50)
|
||||
--leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true)
|
||||
|
|
|
|||
|
|
@ -48,9 +48,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
|||
--iptables-masquerade-bit int32 If using the pure iptables proxy, the bit of the fwmark space to mark packets requiring SNAT with. Must be within the range [0, 31]. (default 14)
|
||||
--iptables-min-sync-period duration The minimum interval of how often the iptables rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m').
|
||||
--iptables-sync-period duration The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m'). Must be greater than 0. (default 30s)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 5)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 5)
|
||||
--kubeconfig string Path to kubeconfig file with authorization information (the master location is set by the master flag).
|
||||
--masquerade-all If using the pure iptables proxy, SNAT everything
|
||||
--master string The address of the Kubernetes API server (overrides any value in kubeconfig)
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false)
|
|||
StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
|
||||
--hard-pod-affinity-symmetric-weight int RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. (default 1)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 100)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 100)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 50)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 50)
|
||||
--kubeconfig string Path to kubeconfig file with authorization and master location information.
|
||||
--leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true)
|
||||
--leader-elect-lease-duration duration The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled. (default 15s)
|
||||
|
|
|
|||
|
|
@ -107,9 +107,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
|||
--image-service-endpoint string [Experimental] The unix socket endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. The endpoint is used only when CRI integration is enabled (--experimental-cri)
|
||||
--iptables-drop-bit int32 The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15)
|
||||
--iptables-masquerade-bit int32 The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps int32 QPS to use while talking with kubernetes apiserver (default 5)
|
||||
--kube-api-qps int32 QPS to use while talking with Kubernetes apiserver (default 5)
|
||||
--kube-reserved mapStringString A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs that describe resources reserved for kubernetes system components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none]
|
||||
--kubeconfig string Path to a kubeconfig file, specifying how to connect to the API server. --api-servers will be used for the location unless --require-kubeconfig is set. (default "/var/lib/kubelet/kubeconfig")
|
||||
--kubelet-cgroups string Optional absolute name of cgroups to create and run the Kubelet in.
|
||||
|
|
@ -118,7 +118,7 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
|||
--make-iptables-util-chains If true, kubelet will ensure iptables utility rules are present on host. (default true)
|
||||
--manifest-url string URL for accessing the container manifest
|
||||
--manifest-url-header string HTTP header to use when accessing the manifest URL, with the key separated from the value with a ':', as in 'key:value'
|
||||
--master-service-namespace string The namespace from which the kubernetes master services should be injected into pods (default "default")
|
||||
--master-service-namespace string The namespace from which the Kubernetes master services should be injected into pods (default "default")
|
||||
--max-open-files int Number of files that can be opened by Kubelet process. [default=1000000] (default 1000000)
|
||||
--max-pods int32 Number of Pods that can run on this Kubelet. (default 110)
|
||||
--minimum-image-ttl-duration duration Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. Default: '2m' (default 2m0s)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ You may want to set up multiple Kubernetes clusters, both to
|
|||
have clusters in different regions to be nearer to your users, and to tolerate failures and/or invasive maintenance.
|
||||
This document describes some of the issues to consider when making a decision about doing so.
|
||||
|
||||
If you decide to have multiple clusters, kubernetes provides a way to [federate them](/docs/admin/federation/)
|
||||
If you decide to have multiple clusters, Kubernetes provides a way to [federate them](/docs/admin/federation/)
|
||||
|
||||
## Scope of a single cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Let's create some content.
|
|||
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
```
|
||||
We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
|
||||
Note that `kubectl run` creates deployments only on kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details.
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -244,6 +244,6 @@ on each kubelet where you want to reserve resources.
|
|||
|
||||
## API Object
|
||||
|
||||
Node is a top-level resource in the kubernetes REST API. More details about the
|
||||
Node is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [Node API
|
||||
object](/docs/api-reference/v1/definitions/#_v1_node).
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
---
|
||||
# API Reference
|
||||
|
||||
Use the following reference docs to understand the kubernetes REST API for various API group versions:
|
||||
Use the following reference docs to understand the Kubernetes REST API for various API group versions:
|
||||
|
||||
* v1: [operations](/docs/api-reference/v1/operations.html), [model definitions](/docs/api-reference/v1/definitions.html)
|
||||
* extensions/v1beta1: [operations](/docs/api-reference/extensions/v1beta1/operations.html), [model definitions](/docs/api-reference/extensions/v1beta1/definitions.html)
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Example: `beta.kubernetes.io/os=linux`
|
|||
Used on: Node
|
||||
|
||||
Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems
|
||||
in your cluster (although currently Linux is the only OS supported by kubernetes).
|
||||
in your cluster (although currently Linux is the only OS supported by Kubernetes).
|
||||
|
||||
## kubernetes.io/hostname
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Used on: Node
|
|||
|
||||
Kubelet populates this with the instance type as defined by the `cloudprovider`. It will not be set if
|
||||
not using a cloudprovider. This can be handy if you want to target certain workloads to certain instance
|
||||
types, but typically you want to rely on the kubernetes scheduler to perform resource-based scheduling,
|
||||
types, but typically you want to rely on the Kubernetes scheduler to perform resource-based scheduling,
|
||||
and you should aim to schedule based on properties rather than on instance types (e.g. require a GPU, instead
|
||||
of requiring a `g2.2xlarge`)
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ title: Running Kubernetes on CenturyLink Cloud
|
|||
* TOC
|
||||
{: toc}
|
||||
|
||||
These scripts handle the creation, deletion and expansion of kubernetes clusters on CenturyLink Cloud.
|
||||
These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
|
||||
|
||||
You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ You can accomplish all these tasks with a single command. We have made the Ansib
|
|||
|
||||
If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
|
||||
- Submit a github issue
|
||||
- Send an email to kubernetes AT ctl DOT io
|
||||
- Send an email to Kubernetes AT ctl DOT io
|
||||
- Visit http://info.ctl.io/kubernetes
|
||||
|
||||
## Clusters of VMs or Physical Servers, your choice.
|
||||
|
|
@ -212,10 +212,10 @@ We configure the Kubernetes cluster with the following features:
|
|||
* KubeDNS: DNS resolution and service discovery
|
||||
* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
|
||||
* Grafana: Kubernetes/Docker metric dashboard
|
||||
* KubeUI: Simple web interface to view kubernetes state
|
||||
* KubeUI: Simple web interface to view Kubernetes state
|
||||
* Kube Dashboard: New web interface to interact with your cluster
|
||||
|
||||
We use the following to create the kubernetes cluster:
|
||||
We use the following to create the Kubernetes cluster:
|
||||
|
||||
* Kubernetes 1.1.7
|
||||
* Ubuntu 14.04
|
||||
|
|
@ -233,7 +233,7 @@ We use the following to create the kubernetes cluster:
|
|||
|
||||
## Cluster management
|
||||
|
||||
The most widely used tool for managing a kubernetes cluster is the command-line
|
||||
The most widely used tool for managing a Kubernetes cluster is the command-line
|
||||
utility ```kubectl```. If you do not already have a copy of this binary on your
|
||||
administrative machine, you may run the script ```install_kubectl.sh``` which will
|
||||
download it and install it in ```/usr/bin/local```.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Configuring Kubernetes on Fedora via Ansible offers a simple way to quickly crea
|
|||
|
||||
## Prerequisites
|
||||
|
||||
1. Host able to run ansible and able to clone the following repo: [kubernetes](https://github.com/kubernetes/kubernetes.git)
|
||||
1. Host able to run ansible and able to clone the following repo: [Kubernetes](https://github.com/kubernetes/kubernetes.git)
|
||||
2. A Fedora 21+ host to act as cluster master
|
||||
3. As many Fedora 21+ hosts as you would like, that act as cluster nodes
|
||||
|
||||
|
|
@ -101,9 +101,9 @@ Although the default value of variables in `~/contrib/ansible/group_vars/all.yml
|
|||
edit: ~/contrib/ansible/group_vars/all.yml
|
||||
```
|
||||
|
||||
**Configure access to kubernetes packages**
|
||||
**Configure access to Kubernetes packages**
|
||||
|
||||
Modify `source_type` as below to access kubernetes packages through the package manager.
|
||||
Modify `source_type` as below to access Kubernetes packages through the package manager.
|
||||
|
||||
```yaml
|
||||
source_type: packageManager
|
||||
|
|
@ -156,7 +156,7 @@ cd ~/contrib/ansible/
|
|||
|
||||
That's all there is to it. It's really that easy. At this point you should have a functioning Kubernetes cluster.
|
||||
|
||||
**Show kubernetes nodes**
|
||||
**Show Kubernetes nodes**
|
||||
|
||||
Run the following on the kube-master:
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ fed-node = 192.168.121.65
|
|||
|
||||
**Prepare the hosts:**
|
||||
|
||||
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with kubernetes-0.18 and beyond.
|
||||
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond.
|
||||
* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the changing the `enable=0` to `enable=1` for extras.
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ If you are on MacOS and using brew, you can install with:
|
|||
brew install kubectl
|
||||
```
|
||||
|
||||
The homebrew project is independent from kubernetes, so do check that the version is
|
||||
The homebrew project is independent from Kubernetes, so do check that the version is
|
||||
sufficiently up-to-date using `kubectl version`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ plugins, if required.
|
|||
|
||||
### Reusing the Docker daemon
|
||||
|
||||
When using a single VM of kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
|
||||
When using a single VM of Kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
|
||||
|
||||
To be able to work with the docker daemon on your mac/linux host use the [docker-env command](./docs/minikube_docker-env.md) in your shell:
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ The fix is to update /etc/sysconfig/docker to ensure that minikube's environment
|
|||
> fi
|
||||
```
|
||||
|
||||
Remember to turn off the imagePullPolicy:Always, as otherwise kubernetes won't use images you built locally.
|
||||
Remember to turn off the imagePullPolicy:Always, as otherwise Kubernetes won't use images you built locally.
|
||||
|
||||
## Managing your Cluster
|
||||
|
||||
|
|
@ -312,7 +312,7 @@ For more information about minikube, see the [proposal](https://github.com/kuber
|
|||
* **Development Guide**: See [CONTRIBUTING.md](https://github.com/kubernetes/minikube/blob/master/CONTRIBUTING.md) for an overview of how to send pull requests.
|
||||
* **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://github.com/kubernetes/minikube/blob/master/BUILD_GUIDE.md)
|
||||
* **Adding a New Dependency**: For instructions on how to add a new dependency to minikube see the [adding dependencies guide](https://github.com/kubernetes/minikube/blob/master/ADD_DEPENDENCY.md)
|
||||
* **Updating Kubernetes**: For instructions on how to add a new dependency to minikube see the [updating kubernetes guide](https://github.com/kubernetes/minikube/blob/master/UPDATE_KUBERNETES.md)
|
||||
* **Updating Kubernetes**: For instructions on how to add a new dependency to minikube see the [updating Kubernetes guide](https://github.com/kubernetes/minikube/blob/master/UPDATE_KUBERNETES.md)
|
||||
|
||||
## Community
|
||||
|
||||
|
|
|
|||
|
|
@ -822,7 +822,7 @@ of their purpose is in the admin guide](/docs/admin/cluster-components/#addons).
|
|||
Notes for setting up each cluster service are given below:
|
||||
|
||||
* Cluster DNS:
|
||||
* required for many kubernetes examples
|
||||
* required for many Kubernetes examples
|
||||
* [Setup instructions](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/)
|
||||
* [Admin Guide](/docs/admin/dns/)
|
||||
* Cluster-level Logging
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ assignees:
|
|||
|
||||
---
|
||||
|
||||
This document describes how to deploy kubernetes on ubuntu nodes, 1 master and 3 nodes involved
|
||||
This document describes how to deploy Kubernetes on ubuntu nodes, 1 master and 3 nodes involved
|
||||
in the given examples. You can scale to **any number of nodes** by changing some settings with ease.
|
||||
The original idea was heavily inspired by @jainvipin 's ubuntu single node
|
||||
work, which has been merge into this document.
|
||||
|
|
@ -36,7 +36,7 @@ Ubuntu 15 which uses systemd instead of upstart.
|
|||
|
||||
### Set up working directory
|
||||
|
||||
Clone the kubernetes github repo locally
|
||||
Clone the Kubernetes github repo locally
|
||||
|
||||
```shell
|
||||
$ git clone --depth 1 https://github.com/kubernetes/kubernetes.git
|
||||
|
|
@ -101,7 +101,7 @@ acts as both master and node, "a" stands for master, "i" stands for node.
|
|||
|
||||
The `NUM_NODES` variable defines the total number of nodes.
|
||||
|
||||
The `SERVICE_CLUSTER_IP_RANGE` variable defines the kubernetes service IP range. Please make sure
|
||||
The `SERVICE_CLUSTER_IP_RANGE` variable defines the Kubernetes service IP range. Please make sure
|
||||
that you do have a valid private ip range defined here, because some IaaS provider may reserve private ips.
|
||||
You can use below three private network range according to rfc1918. Besides you'd better not choose the one
|
||||
that conflicts with your own private network range.
|
||||
|
|
@ -138,7 +138,7 @@ bring up the whole cluster.
|
|||
$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
|
||||
```
|
||||
|
||||
The scripts automatically copy binaries and config files to all the machines via `scp` and start kubernetes
|
||||
The scripts automatically copy binaries and config files to all the machines via `scp` and start Kubernetes
|
||||
service on them. The only thing you need to do is to type the sudo password when promoted.
|
||||
|
||||
```shell
|
||||
|
|
@ -211,7 +211,7 @@ After some time, you can use `$ kubectl get pods --namespace=kube-system` to see
|
|||
|
||||
We are working on these features which we'd like to let everybody know:
|
||||
|
||||
1. Run kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube),
|
||||
1. Run Kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube),
|
||||
to eliminate OS-distro differences.
|
||||
2. Tearing Down scripts: clear and re-create the whole stack by one click.
|
||||
|
||||
|
|
@ -239,7 +239,7 @@ $ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
|
|||
|
||||
## Upgrading a Cluster
|
||||
|
||||
If you already have a kubernetes cluster, and want to upgrade to a new version,
|
||||
If you already have a Kubernetes cluster, and want to upgrade to a new version,
|
||||
you can use following command in `cluster/` directory to update the whole cluster
|
||||
or a specified node to a new version.
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ The script will not delete any resources of your cluster, it just replaces the b
|
|||
|
||||
### Test it out
|
||||
|
||||
You can use the `kubectl` command to check if the newly upgraded kubernetes cluster is working correctly.
|
||||
You can use the `kubectl` command to check if the newly upgraded Kubernetes cluster is working correctly.
|
||||
|
||||
To make sure the version of the upgraded cluster is what you expect, you will find these commands helpful.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ This task shows you how to delete a StatefulSet.
|
|||
|
||||
### Deleting a StatefulSet
|
||||
|
||||
You can delete a StatefulSet in the same way you delete other resources in kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
|
||||
You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml>
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ You may also find the Stack Overflow topics relevant:
|
|||
|
||||
Someone else from the community may have already asked a similar question or may
|
||||
be able to help with your problem. The Kubernetes team will also monitor
|
||||
[posts tagged kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
|
||||
[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
|
||||
If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)!
|
||||
|
||||
### Slack
|
||||
|
|
|
|||
|
|
@ -294,7 +294,7 @@ SPECIAL_TYPE_KEY=charm
|
|||
### Use-Case: Set command-line arguments with ConfigMap
|
||||
|
||||
ConfigMaps can also be used to set the value of the command or arguments in a container. This is
|
||||
accomplished using the kubernetes substitution syntax `$(VAR_NAME)`. Consider the ConfigMap:
|
||||
accomplished using the Kubernetes substitution syntax `$(VAR_NAME)`. Consider the ConfigMap:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myconfigmap.yaml
|
|||
```
|
||||
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated ConfigMap is created, the federation control plane will create
|
||||
a matching ConfigMap in all underlying kubernetes clusters.
|
||||
a matching ConfigMap in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
|
|||
|
|
@ -44,11 +44,11 @@ kubectl --context=federation-cluster create -f mydaemonset.yaml
|
|||
```
|
||||
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated Daemonset is created, the federation control plane will create
|
||||
a matching DaemonSet in all underlying kubernetes clusters.
|
||||
a matching DaemonSet in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
|
|||
|
|
@ -47,11 +47,11 @@ kubectl --context=federation-cluster create -f mydeployment.yaml
|
|||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated Deployment is created, the federation control plane will create
|
||||
a Deployment in all underlying kubernetes clusters.
|
||||
a Deployment in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ general.
|
|||
Events in federation control plane (referred to as "federation events" in
|
||||
this guide) are very similar to the traditional Kubernetes
|
||||
Events providing the same functionality.
|
||||
Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters.
|
||||
Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters.
|
||||
|
||||
Federation controllers create events as they process API resources to surface to the
|
||||
user, the state that they are in.
|
||||
|
|
|
|||
|
|
@ -277,7 +277,7 @@ where:
|
|||
|
||||
1. `firewall-rule-name` can be any name.
|
||||
2. `[<service-nodeports>]` is the comma separated list of node ports corresponding to the services that back the Federated Ingress.
|
||||
3. [<target-tags>] is the comma separated list of the target tags assigned to the nodes in a kubernetes cluster.
|
||||
3. [<target-tags>] is the comma separated list of the target tags assigned to the nodes in a Kubernetes cluster.
|
||||
4. <network-name> is the name of the network where the firewall rule must be installed.
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Federation User Guide
|
||||
---
|
||||
|
||||
This guide explains how we can manage multiple kubernetes clusters using
|
||||
This guide explains how we can manage multiple Kubernetes clusters using
|
||||
federation.
|
||||
[Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md)
|
||||
details the use cases motivating cluster federation.
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myns.yaml
|
|||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated namespace is created, the federation control plane will create
|
||||
a matching namespace in all underlying kubernetes clusters.
|
||||
a matching namespace in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
@ -64,7 +64,7 @@ the Federated Namespace that you created above.
|
|||
|
||||
You can update a federated namespace as you would update a Kubernetes
|
||||
namespace, just send the request to federation apiserver instead of sending it
|
||||
to a specific kubernetes cluster.
|
||||
to a specific Kubernetes cluster.
|
||||
Federation control plan will ensure that whenever the federated namespace is
|
||||
updated, it updates the corresponding namespaces in all underlying clusters to
|
||||
match it.
|
||||
|
|
@ -73,7 +73,7 @@ match it.
|
|||
|
||||
You can delete a federated namespace as you would delete a Kubernetes
|
||||
namespace, just send the request to federation apiserver instead of sending it
|
||||
to a specific kubernetes cluster.
|
||||
to a specific Kubernetes cluster.
|
||||
|
||||
For example, you can do that using kubectl by running:
|
||||
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myrs.yaml
|
|||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated replica set is created, the federation control plane will create
|
||||
a replica set in all underlying kubernetes clusters.
|
||||
a replica set in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
|
|||
|
|
@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f mysecret.yaml
|
|||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated secret is created, the federation control plane will create
|
||||
a matching secret in all underlying kubernetes clusters.
|
||||
a matching secret in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ A Job can also be used to run multiple pods in parallel.
|
|||
### extensions/v1beta1.Job is deprecated
|
||||
|
||||
Starting from version 1.5 `extensions/v1beta1.Job` is being deprecated, with a plan to be removed in
|
||||
version 1.6 of kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
|
||||
version 1.6 of Kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
|
||||
Please use `batch/v1.Job` instead.
|
||||
|
||||
## Running an example Job
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ If you have a large number of job objects, you may find that:
|
|||
concurrent requests to a shared resource, such as a database,
|
||||
used by all the pods in the job.
|
||||
- very large numbers of jobs created at once overload the
|
||||
kubernetes apiserver, controller, or scheduler.
|
||||
Kubernetes apiserver, controller, or scheduler.
|
||||
|
||||
In this case, you can consider one of the
|
||||
other [job patterns](/docs/user-guide/jobs/#job-patterns).
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Authenticating Across Clusters with kubeconfig
|
||||
---
|
||||
|
||||
Authentication in kubernetes can differ for different individuals.
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Authenticating Across Clusters with kubeconfig
|
||||
---
|
||||
|
||||
Authentication in Kubernetes can differ for different individuals.
|
||||
|
||||
- A running kubelet might have one way of authenticating (i.e. certificates).
|
||||
- Users might have a different way of authenticating (i.e. tokens).
|
||||
|
|
@ -82,8 +82,8 @@ clusters:
|
|||
name: pig-cluster
|
||||
```
|
||||
|
||||
A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
|
||||
qualified url for the kubernetes apiserver, as well as the cluster's certificate
|
||||
A `cluster` contains endpoint data for a Kubernetes cluster. This includes the fully
|
||||
qualified url for the Kubernetes apiserver, as well as the cluster's certificate
|
||||
authority or `insecure-skip-tls-verify: true`, if the cluster's serving
|
||||
certificate is not signed by a system trusted certificate authority.
|
||||
A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
|
||||
|
|
@ -103,7 +103,7 @@ users:
|
|||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
A `user` defines client credentials for authenticating to a kubernetes cluster. A
|
||||
A `user` defines client credentials for authenticating to a Kubernetes cluster. A
|
||||
`user` has a name (nickname) which acts as its key within the list of user entries
|
||||
after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
|
||||
`client-key`, `token`, and `username/password`. `username/password` and `token`
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
|||
### Synopsis
|
||||
|
||||
|
||||
Creates an autoscaler that automatically chooses and sets the number of pods that run in a kubernetes cluster.
|
||||
Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster.
|
||||
|
||||
Looks up a Deployment, ReplicaSet, or ReplicationController by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Dump lots of relevant info for debugging and diagnosis
|
|||
### Synopsis
|
||||
|
||||
|
||||
Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
|
||||
Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, Kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
|
||||
|
||||
The command also dumps the logs of all of the pods in the cluster, these logs are dumped into different directories based on namespace and pod name.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,17 +9,17 @@ Run a proxy to the Kubernetes API server
|
|||
### Synopsis
|
||||
|
||||
|
||||
To proxy all of the kubernetes api and nothing else, use:
|
||||
To proxy all of the Kubernetes api and nothing else, use:
|
||||
|
||||
$ kubectl proxy --api-prefix=/
|
||||
|
||||
To proxy only part of the kubernetes api and also some static files:
|
||||
To proxy only part of the Kubernetes api and also some static files:
|
||||
|
||||
$ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/
|
||||
|
||||
The above lets you 'curl localhost:8001/api/v1/pods'.
|
||||
|
||||
To proxy the entire kubernetes api at a different root, use:
|
||||
To proxy the entire Kubernetes api at a different root, use:
|
||||
|
||||
$ kubectl proxy --api-prefix=/custom/
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
|||
|
||||
## Not All Objects are in a Namespace
|
||||
|
||||
Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||
in some namespace. However namespace resources are not themselves in a namespace.
|
||||
And low-level resources, such as [nodes](/docs/admin/node) and
|
||||
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
|
||||
|
|
|
|||
|
|
@ -178,9 +178,9 @@ Force deletions can be potentially dangerous for some pods and should be perform
|
|||
|
||||
## Privileged mode for pod containers
|
||||
|
||||
From kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.
|
||||
From Kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet.
|
||||
|
||||
If the master is running kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
|
||||
If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state.
|
||||
If user calls `kubectl describe pod FooPodName`, user can see the reason why the pod is in pending state. The events table in the describe command output will say:
|
||||
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
|
||||
|
||||
|
|
@ -191,6 +191,6 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
|
|||
|
||||
## API Object
|
||||
|
||||
Pod is a top-level resource in the kubernetes REST API. More details about the
|
||||
Pod is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [Pod API
|
||||
object](/docs/api-reference/v1/definitions/#_v1_pod).
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ There are additional flags that can be specified. For a complete list, run:
|
|||
|
||||
## Deleting a pod
|
||||
|
||||
If your pod was created using the `run` command, kubernetes creates a
|
||||
If your pod was created using the `run` command, Kubernetes creates a
|
||||
[Deployment](/docs/user-guide/deployments/)
|
||||
to manage the pod. Pods managed by a Deployment are rescheduled if
|
||||
they go away, including being deleted by `kubectl delete pod`. To permanently
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl
|
|||
|
||||
If you downloaded a pre-compiled [release](https://github.com/kubernetes/kubernetes/releases), kubectl will be under `platforms/<os>/<arch>` from the tar bundle.
|
||||
|
||||
If you compiled kubernetes from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
|
||||
If you compiled Kubernetes from source, kubectl should be either under `_output/local/bin/<os>/<arch>` or `_output/dockerized/bin/<os>/<arch>`.
|
||||
|
||||
Copy or move kubectl into a directory already in your PATH (e.g. `/usr/local/bin`). For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ The ReplicationController is intended to be a composable building-block primitiv
|
|||
|
||||
## API Object
|
||||
|
||||
Replication controller is a top-level resource in the kubernetes REST API. More details about the
|
||||
Replication controller is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [ReplicationController API
|
||||
object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
|
||||
|
||||
|
|
|
|||
|
|
@ -486,7 +486,7 @@ Create a secret containing some ssh keys:
|
|||
$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
|
||||
```
|
||||
|
||||
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to have accessible to all the users with whom you share the kubernetes cluster, and can revoke if they are compromised.
|
||||
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to have accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
|
||||
|
||||
Now we can create a pod which references the secret with the ssh key and
|
||||
|
|
|
|||
|
|
@ -655,7 +655,7 @@ through a load-balancer, though in those cases the client IP does get altered.
|
|||
|
||||
## API Object
|
||||
|
||||
Service is a top-level resource in the kubernetes REST API. More details about the
|
||||
Service is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [Service API
|
||||
object](/docs/api-reference/v1/definitions/#_v1_service).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue