Merge branch 'master' into all-user-doc
This commit is contained in:
@@ -24,7 +24,7 @@ following diagram:
|
||||
In a typical Kubernetes cluster, the API served on port 443. A TLS connection is
|
||||
established. The API server presents a certificate. This certificate is
|
||||
often self-signed, so `$USER/.kube/config` on the user's machine typically
|
||||
contains the root certficate for the API server's certificate, which when specified
|
||||
contains the root certificate for the API server's certificate, which when specified
|
||||
is used in place of the system default root certificates. This certificate is typically
|
||||
automatically written into your `$USER/.kube/config` when you create a cluster yourself
|
||||
using `kube-up.sh`. If the cluster has multiple users, then the creator needs to share
|
||||
@@ -86,7 +86,7 @@ For version 1.2, clusters created by `kube-up.sh` are configured so that no auth
|
||||
required for any request.
|
||||
|
||||
As of version 1.3, clusters created by `kube-up.sh` are configured so that the ABAC authorization
|
||||
modules is enabled. However, its input file is initially set to allow all users to do all
|
||||
modules are enabled. However, its input file is initially set to allow all users to do all
|
||||
operations. The cluster administrator needs to edit that file, or configure a different authorizer
|
||||
to restrict what users can do.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
|
||||
* [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/ku
|
||||
|
||||
When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`.
|
||||
|
||||
Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
|
||||
Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
|
||||
|
||||
An example request body:
|
||||
|
||||
@@ -151,7 +151,7 @@ An example request body:
|
||||
}
|
||||
```
|
||||
|
||||
The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s “spec” field is ignored and may be omitted. A permissive response would return:
|
||||
The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return:
|
||||
|
||||
```
|
||||
{
|
||||
|
||||
@@ -384,7 +384,7 @@ Specifying the default profile to apply to containers when none is provided:
|
||||
- **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
- **value**: a profile reference, described above
|
||||
|
||||
Specifying the list of profiles Pod containers are allowed to specify:
|
||||
Specifying the list of profiles Pod containers is allowed to specify:
|
||||
|
||||
- **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
- **value**: a comma-separated list of profile references (described above)
|
||||
|
||||
@@ -444,7 +444,7 @@ The script will generate three files: `ca.crt`, `server.crt`, and `server.key`.
|
||||
Finally, add the following parameters into API server start parameters:
|
||||
|
||||
- `--client-ca-file=/srv/kubernetes/ca.crt`
|
||||
- `--tls-cert-file=/srv/kubernetes/server.cert`
|
||||
- `--tls-cert-file=/srv/kubernetes/server.crt`
|
||||
- `--tls-private-key-file=/srv/kubernetes/server.key`
|
||||
|
||||
#### easyrsa
|
||||
@@ -468,7 +468,7 @@ Finally, add the following parameters into API server start parameters:
|
||||
1. Fill in and add the following parameters into the API server start parameters:
|
||||
|
||||
--client-ca-file=/yourdirectory/ca.crt
|
||||
--tls-cert-file=/yourdirectory/server.cert
|
||||
--tls-cert-file=/yourdirectory/server.crt
|
||||
--tls-private-key-file=/yourdirectory/server.key
|
||||
|
||||
#### openssl
|
||||
|
||||
@@ -330,7 +330,7 @@ roleRef:
|
||||
|
||||
Finally a `ClusterRoleBinding` may be used to grant permissions in all
|
||||
namespaces. The following `ClusterRoleBinding` allows any user in the group
|
||||
"manager" to read secrets in any namepsace.
|
||||
"manager" to read secrets in any namespace.
|
||||
|
||||
```yaml
|
||||
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
|
||||
|
||||
@@ -61,12 +61,12 @@ selects a node for them to run on.
|
||||
|
||||
### addons
|
||||
|
||||
Addons are pods and services that implement cluster features. They don't run on
|
||||
the master VM, but currently the default setup scripts that make the API calls
|
||||
to create these pods and services does run on the master VM. See:
|
||||
[kube-master-addons](http://releases.k8s.io/HEAD/cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh)
|
||||
Addons are pods and services that implement cluster features. The pods may be managed
|
||||
by Deployments, ReplicationContollers, etc. Namespaced addon objects are created in
|
||||
the "kube-system" namespace.
|
||||
|
||||
Addon objects are created in the "kube-system" namespace.
|
||||
Addon manager takes the responsibility for creating and maintaining addon resources.
|
||||
See [here](http://releases.k8s.io/HEAD/cluster/addons) for more details.
|
||||
|
||||
#### DNS
|
||||
|
||||
|
||||
@@ -92,7 +92,7 @@ an extended period of time (10min but it may change in the future).
|
||||
Cluster autoscaler is configured per instance group (GCE) or node pool (GKE).
|
||||
|
||||
If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
|
||||
To configure cluser autoscaler you have to set 3 environment variables:
|
||||
To configure cluster autoscaler you have to set 3 environment variables:
|
||||
|
||||
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
|
||||
* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
|
||||
@@ -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.
|
||||
|
||||
@@ -89,7 +89,7 @@ Mitigations:
|
||||
- Mitigates: Apiserver VM shutdown or apiserver crashing
|
||||
- Mitigates: Supporting services VM shutdown or crashes
|
||||
|
||||
- Action use IaaS providers reliable storage (e.g GCE PD or AWS EBS volume) for VMs with apiserver+etcd
|
||||
- Action use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd
|
||||
- Mitigates: Apiserver backing storage lost
|
||||
|
||||
- Action: Use (experimental) [high-availability](/docs/admin/high-availability) configuration
|
||||
|
||||
+15
-16
@@ -7,20 +7,20 @@ title: Daemon Sets
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## What is a Daemon Set?
|
||||
## What is a DaemonSet?
|
||||
|
||||
A _Daemon Set_ ensures that all (or some) nodes run a copy of a pod. As nodes are added to the
|
||||
A _DaemonSet_ ensures that all (or some) nodes run a copy of a pod. As nodes are added to the
|
||||
cluster, pods are added to them. As nodes are removed from the cluster, those pods are garbage
|
||||
collected. Deleting a Daemon Set will clean up the pods it created.
|
||||
collected. Deleting a DaemonSet will clean up the pods it created.
|
||||
|
||||
Some typical uses of a Daemon Set are:
|
||||
Some typical uses of a DaemonSet are:
|
||||
|
||||
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
|
||||
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
|
||||
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
|
||||
https://github.com/prometheus/node_exporter), `collectd`, New Relic agent, or Ganglia `gmond`.
|
||||
|
||||
In a simple case, one Daemon Set, covering all nodes, would be used for each type of daemon.
|
||||
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
|
||||
A more complex setup might use multiple DaemonSets would be used for a single type of daemon,
|
||||
but with different flags and/or different memory and cpu requests for different hardware types.
|
||||
|
||||
@@ -74,7 +74,7 @@ a node for testing.
|
||||
|
||||
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
|
||||
create pods on nodes which match that [node
|
||||
selector](/docs/user-guide/node-selection/).
|
||||
selector](/docs/user-guide/node-selection/).
|
||||
If you specify a `scheduler.alpha.kubernetes.io/affinity` annotation in `.spec.template.metadata.annotations`,
|
||||
then DaemonSet controller will create pods on nodes which match that [node affinity](../../user-guide/node-selection/#alpha-feature-in-kubernetes-v12-node-affinity).
|
||||
|
||||
@@ -88,18 +88,17 @@ created by the Daemon controller have the machine already selected (`.spec.nodeN
|
||||
when the pod is created, so it is ignored by the scheduler). Therefore:
|
||||
|
||||
- the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
|
||||
by the daemon set controller.
|
||||
- daemon set controller can make pods even when the scheduler has not been started, which can help cluster
|
||||
by the DaemonSet controller.
|
||||
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
|
||||
bootstrap.
|
||||
|
||||
## Communicating with DaemonSet Pods
|
||||
|
||||
Some possible patterns for communicating with pods in a DaemonSet are:
|
||||
|
||||
- **Push**: Pods in the Daemon Set are configured to send updates to another service, such
|
||||
- **Push**: Pods in the DaemonSet are configured to send updates to another service, such
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the Daemon Set use a `hostPort`, so that the pods are reachable
|
||||
via the node IPs. Clients knows the list of nodes ips somehow, and know the port by convention.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
@@ -126,11 +125,11 @@ You cannot update a DaemonSet.
|
||||
|
||||
Support for updating DaemonSets and controlled updating of nodes is planned.
|
||||
|
||||
## Alternatives to Daemon Set
|
||||
## Alternatives to DaemonSet
|
||||
|
||||
### Init Scripts
|
||||
|
||||
It is certainly possible to run daemon processes by directly starting them on a node (e.g using
|
||||
It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
|
||||
`init`, `upstartd`, or `systemd`). This is perfectly fine. However, there are several advantages to
|
||||
running such processes via a DaemonSet:
|
||||
|
||||
@@ -145,9 +144,9 @@ running such processes via a DaemonSet:
|
||||
### Bare Pods
|
||||
|
||||
It is possible to create pods directly which specify a particular node to run on. However,
|
||||
a Daemon Set replaces pods that are deleted or terminated for any reason, such as in the case of
|
||||
a DaemonSet replaces pods that are deleted or terminated for any reason, such as in the case of
|
||||
node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should
|
||||
use a Daemon Set rather than creating individual pods.
|
||||
use a DaemonSet rather than creating individual pods.
|
||||
|
||||
### Static Pods
|
||||
|
||||
@@ -159,7 +158,7 @@ in cluster bootstrapping cases. Also, static pods may be deprecated in the futu
|
||||
|
||||
### Replication Controller
|
||||
|
||||
Daemon Set are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that
|
||||
DaemonSet are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that
|
||||
they both create pods, and those pods have processes which are not expected to terminate (e.g. web servers,
|
||||
storage servers).
|
||||
|
||||
|
||||
+1
-1
@@ -77,7 +77,7 @@ For example, a pod with ip `1.2.3.4` in the namespace `default` with a DNS name
|
||||
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
|
||||
|
||||
With v1.2, users can specify a Pod annotation, `pod.beta.kubernetes.io/hostname`, to specify what the Pod's hostname should be.
|
||||
The Pod annotation, if specified, takes precendence over the Pod's name, to be the hostname of the pod.
|
||||
The Pod annotation, if specified, takes precedence over the Pod's name, to be the hostname of the pod.
|
||||
For example, given a Pod with annotation `pod.beta.kubernetes.io/hostname: my-pod-name`, the Pod will have its hostname set to "my-pod-name".
|
||||
|
||||
With v1.3, the PodSpec has a `hostname` field, which can be used to specify the Pod's hostname. This field value takes precedence over the
|
||||
|
||||
@@ -26,7 +26,7 @@ federation-apiserver
|
||||
--admission-control-config-file string File with admission control configuration.
|
||||
--advertise-address ip The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used.
|
||||
--anonymous-auth Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true)
|
||||
--apiserver-count int The number of apiservers running in the cluster. (default 1)
|
||||
--apiserver-count int The number of apiservers running in the cluster. Must be a positive number. (default 1)
|
||||
--audit-log-maxage int The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
|
||||
--audit-log-maxbackup int The maximum number of old audit log files to retain.
|
||||
--audit-log-maxsize int The maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
|
||||
|
||||
@@ -110,7 +110,7 @@ $ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh build_image
|
||||
$ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh push
|
||||
```
|
||||
|
||||
Note: This is going to overwite the values you might have set for
|
||||
Note: This is going to overwrite the values you might have set for
|
||||
`apiserverRegistry`, `apiserverVersion`, `controllerManagerRegistry` and
|
||||
`controllerManagerVersion` in your `${FEDERATION_OUTPUT_ROOT}/values.yaml`
|
||||
file. Hence, it is not recommend to customize these values in
|
||||
@@ -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:
|
||||
|
||||
@@ -24,7 +24,7 @@ If true, reads will be directed to leader etcd replica.
|
||||
Setting this value to true is optional: reads will be more reliable but will also be slower.
|
||||
|
||||
Optionally, you can specify a GCE zone where the first master replica is to be created.
|
||||
Set the the following flag:
|
||||
Set the following flag:
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run.
|
||||
|
||||
|
||||
+3
-3
@@ -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
|
||||
|
||||
@@ -27,7 +27,7 @@ kube-apiserver
|
||||
--advertise-address ip The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used.
|
||||
--allow-privileged If true, allow privileged containers.
|
||||
--anonymous-auth Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true)
|
||||
--apiserver-count int The number of apiservers running in the cluster. (default 1)
|
||||
--apiserver-count int The number of apiservers running in the cluster. Must be a positive number. (default 1)
|
||||
--audit-log-maxage int The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
|
||||
--audit-log-maxbackup int The maximum number of old audit log files to retain.
|
||||
--audit-log-maxsize int The maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -242,7 +242,7 @@ Once the cluster is up, you can grab the admin credentials from the master node
|
||||
## Environment variables
|
||||
|
||||
There are some environment variables that modify the way that `kubeadm` works. Most users will have no need to set these.
|
||||
These enviroment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file.
|
||||
These environment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file.
|
||||
|
||||
| Variable | Default | Description |
|
||||
| --- | --- | --- |
|
||||
|
||||
@@ -9,7 +9,7 @@ title: TLS bootstrapping
|
||||
|
||||
## Overview
|
||||
|
||||
This document describes how to set up TLS client certificate boostrapping for kubelets.
|
||||
This document describes how to set up TLS client certificate bootstrapping for kubelets.
|
||||
Kubernetes 1.4 introduces an experimental API for requesting certificates from a cluster-level
|
||||
Certificate Authority (CA). The first supported use of this API is the provisioning of TLS client
|
||||
certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
|
||||
@@ -17,7 +17,7 @@ and progress on the feature is being tracked as [feature #43](https://github.com
|
||||
|
||||
## apiserver configuration
|
||||
|
||||
You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet boostrap-specific group.
|
||||
You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group.
|
||||
This group will later be used in the controller-manager configuration to scope approvals in the default approval
|
||||
controller. As this feature matures, you should ensure tokens are bound to an RBAC policy which limits requests
|
||||
using the bootstrap token to only be able to make requests related to certificate provisioning. When RBAC policy
|
||||
|
||||
@@ -78,9 +78,9 @@ kubelet
|
||||
--experimental-allowed-unsafe-sysctls stringSlice Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk.
|
||||
--experimental-bootstrap-kubeconfig string <Warning: Experimental feature> Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir.
|
||||
--experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created.
|
||||
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount
|
||||
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
|
||||
--experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint.
|
||||
--experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6.
|
||||
--experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary option to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6.
|
||||
--experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.
|
||||
--experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount.
|
||||
--experimental-nvidia-gpus int32 Number of NVIDIA GPU devices on this node. Only 0 (default) and 1 are currently supported.
|
||||
@@ -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)
|
||||
|
||||
@@ -184,7 +184,7 @@ Note that this pod specifies explicit resource *limits* and *requests* so it did
|
||||
default values.
|
||||
|
||||
Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node
|
||||
that runs the container unless the administrator deploys the kubelet with the folllowing flag:
|
||||
that runs the container unless the administrator deploys the kubelet with the following flag:
|
||||
|
||||
```shell
|
||||
$ kubelet --help
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -52,7 +52,7 @@ Second, decide how many clusters should be able to be unavailable at the same ti
|
||||
the number that can be unavailable `U`. If you are not sure, then 1 is a fine choice.
|
||||
|
||||
If it is allowable for load-balancing to direct traffic to any region in the event of a cluster failure, then
|
||||
you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g you want to ensure low latency for all
|
||||
you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g. you want to ensure low latency for all
|
||||
users in the event of a cluster failure), then you need to have `R * (U + 1)` clusters
|
||||
(`U + 1` in each of `R` regions). In any case, try to put each cluster in a different zone.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -32,7 +32,7 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used,
|
||||
|
||||
### Exec
|
||||
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e. if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
|
||||
### CNI
|
||||
|
||||
|
||||
@@ -173,7 +173,7 @@ Lars Kellogg-Stedman.
|
||||
|
||||
[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage’s policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform’s real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ either `kubectl` or addon pod.
|
||||
|
||||
### Kubectl
|
||||
|
||||
This is the recommanded way to start node problem detector outside of GCE. It
|
||||
This is the recommended way to start node problem detector outside of GCE. It
|
||||
provides more flexible management, such as overwriting the default
|
||||
configuration to fit it into your environment or detect
|
||||
customized node problems.
|
||||
@@ -238,7 +238,7 @@ implement a new translator for a new log format.
|
||||
|
||||
## Caveats
|
||||
|
||||
It is recommanded to run the node problem detector in your cluster to monitor
|
||||
It is recommended to run the node problem detector in your cluster to monitor
|
||||
the node health. However, you should be aware that this will introduce extra
|
||||
resource overhead on each node. Usually this is fine, because:
|
||||
|
||||
|
||||
+10
-2
@@ -20,7 +20,15 @@ architecture design doc for more details.
|
||||
|
||||
## Node Status
|
||||
|
||||
A node's status is comprised of the following information.
|
||||
A node's status contains the following information:
|
||||
|
||||
* [Addresses](#Addresses)
|
||||
* ~~[Phase](#Phase)~~ **deprecated**
|
||||
* [Condition](#Condition)
|
||||
* [Capacity](#Capacity)
|
||||
* [Info](#Info)
|
||||
|
||||
Each section is described in detail below.
|
||||
|
||||
### Addresses
|
||||
|
||||
@@ -236,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).
|
||||
|
||||
@@ -330,7 +330,7 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` pods.
|
||||
`kubelet` has been freeing up disk space on demand to keep the node stable.
|
||||
|
||||
As disk based eviction matures, the following `kubelet` flags will be marked for deprecation
|
||||
in favor of the simpler configuation supported around eviction.
|
||||
in favor of the simpler configuration supported around eviction.
|
||||
|
||||
| Existing Flag | New Flag |
|
||||
| ------------- | -------- |
|
||||
|
||||
@@ -30,7 +30,7 @@ given the pods that are already running in the cluster
|
||||
the rescheduler tries to free up space for the add-on by evicting some pods; then the scheduler will schedule the add-on pod.
|
||||
|
||||
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
|
||||
the chosen node gets a temporary taint “CriticalAddonsOnly” before the eviction(s)
|
||||
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
|
||||
(see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)).
|
||||
Each critical add-on has to tolerate it,
|
||||
the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled.
|
||||
@@ -50,11 +50,10 @@ It's enabled by default. It can be disabled:
|
||||
|
||||
### Marking add-on as critical
|
||||
|
||||
To be critical an add-on has to run in `kube-system` namespace (cofigurable via flag)
|
||||
To be critical an add-on has to run in `kube-system` namespace (configurable via flag)
|
||||
and have the following annotations specified:
|
||||
|
||||
* `scheduler.alpha.kubernetes.io/critical-pod` set to empty string
|
||||
* `scheduler.alpha.kubernetes.io/tolerations` set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
|
||||
|
||||
The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ assignees:
|
||||
|
||||
This document describes how sysctls are used within a Kubernetes cluster.
|
||||
|
||||
## What is a _Sysctl_?
|
||||
## What is a Sysctl?
|
||||
|
||||
In Linux, the sysctl interface allows an administrator to modify kernel
|
||||
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
|
||||
|
||||
Reference in New Issue
Block a user