whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into all-user-doc

Browse Source
This commit is contained in:
Jeff Sloyer
2016-12-28 22:00:03 -05:00
committed by GitHub
parent 04a783d373 e2b16a577c
commit 7e4ef9a0be
155 changed files with 1766 additions and 1210 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/accessing-the-api.md
+2 -2
View File
@@ -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.
docs/admin/addons.md
+1 -1
View File
@@ -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.
docs/admin/admission-controllers.md
+2 -2
View File
@@ -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:
```
{
docs/admin/apparmor/index.md
+1 -1
View File
@@ -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)
docs/admin/authentication.md
+2 -2
View File
@@ -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
docs/admin/authorization.md
+1 -1
View File
@@ -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.
docs/admin/cluster-components.md
+5 -5
View File
@@ -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
docs/admin/cluster-management.md
+2 -2
View File
@@ -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.
docs/admin/cluster-troubleshooting.md
+1 -1
View File
@@ -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
docs/admin/daemons.md
+15 -16
View File
@@ -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).
docs/admin/dns.md
+1 -1
View File
@@ -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
docs/admin/federation-apiserver.md
+1 -1
View File
@@ -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.
docs/admin/federation/index.md
+3 -3
View File
@@ -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.
docs/admin/garbage-collection.md
+1 -1
View File
@@ -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:
docs/admin/ha-master-gce.md
+1 -1
View File
@@ -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.
docs/admin/index.md
+3 -3
View File
@@ -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
docs/admin/kube-apiserver.md
+1 -1
View File
@@ -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.
docs/admin/kube-controller-manager.md
+2 -2
View File
@@ -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)
docs/admin/kube-proxy.md
+2 -2
View File
@@ -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)
docs/admin/kube-scheduler.md
+2 -2
View File
@@ -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)
docs/admin/kubeadm.md
+1 -1
View File
@@ -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 |
| --- | --- | --- |
docs/admin/kubelet-tls-bootstrapping.md
+2 -2
View File
@@ -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
docs/admin/kubelet.md
+5 -5
View File
@@ -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)
docs/admin/limitrange/index.md
+1 -1
View File
@@ -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
docs/admin/multi-cluster.md
+2 -2
View File
@@ -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.
docs/admin/namespaces/walkthrough.md
+1 -1
View File
@@ -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
docs/admin/network-plugins.md
+1 -1
View File
@@ -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
docs/admin/networking.md
+1 -1
View File
@@ -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
docs/admin/node-problem.md
+2 -2
View File
@@ -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:
docs/admin/node.md
+10 -2
View File
@@ -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).
docs/admin/out-of-resource.md
+1 -1
View File
@@ -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 |
| ------------- | -------- |
docs/admin/rescheduler.md
+2 -3
View File
@@ -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.
docs/admin/sysctls.md
+1 -1
View File
@@ -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
docs/api-reference/README.md
+1 -1
View File
@@ -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)
docs/api-reference/extensions/v1beta1/definitions.html
+1 -1
View File
@@ -6320,7 +6320,7 @@ Both these may change in the future. Incoming requests are matched against the h
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">path</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a <em>/</em>. If unspecified, the path defaults to a catch all sending traffic to the backend.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a <em>/</em>. If unspecified, the path defaults to a catch all sending traffic to the backend.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>
<td class="tableblock halign-left valign-top"></td>
docs/api-reference/labels-annotations-taints.md
+2 -2
View File
@@ -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`)
docs/federation/api-reference/extensions/v1beta1/definitions.html
+1 -1
View File
@@ -5240,7 +5240,7 @@ Both these may change in the future. Incoming requests are matched against the h
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">path</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a <em>/</em>. If unspecified, the path defaults to a catch all sending traffic to the backend.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a <em>/</em>. If unspecified, the path defaults to a catch all sending traffic to the backend.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>
<td class="tableblock halign-left valign-top"></td>
docs/getting-started-guides/clc.md
+7 -7
View File
@@ -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.
@@ -207,18 +207,18 @@ Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VM
## Cluster Features and Architecture
We configue the Kubernetes cluster with the following features:
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
* Unbuntu 14.04
* Ubuntu 14.04
* Flannel 0.5.4
* Docker 1.9.1-0~trusty
* Etcd 2.2.2
@@ -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```.
docs/getting-started-guides/cloudstack.md
+1 -1
View File
@@ -66,7 +66,7 @@ Some variables can be edited in the `k8s.yml` file.
k8s_instance_type: Tiny
This will start a Kubernetes master node and a number of compute nodes (by default 2).
The `instance_type` and `template` by default are specific to [exoscale](http://exoscale.ch), edit them to specify your CloudStack cloud specific template and instance type (i.e service offering).
The `instance_type` and `template` by default are specific to [exoscale](http://exoscale.ch), edit them to specify your CloudStack cloud specific template and instance type (i.e. service offering).
Check the tasks and templates in `roles/k8s` if you want to modify anything.
docs/getting-started-guides/fedora/fedora_ansible_config.md
+4 -4
View File
@@ -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:
docs/getting-started-guides/fedora/fedora_manual_config.md
+1 -1
View File
@@ -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
docs/getting-started-guides/kops.md
+1 -1
View File
@@ -57,7 +57,7 @@ kops uses DNS for discovery, both inside the cluster and so that you can reach t
from clients.
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
no longer get your clusters confused, you can share clusters with your colleagues unambigiously,
no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
and you can reach them without relying on remembering an IP address.
You can, and probably should, use subdomains to divide your clusters. As our example we will use
docs/getting-started-guides/kubectl.md
+1 -1
View File
@@ -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`.
docs/getting-started-guides/libvirt-coreos.md
+2 -2
View File
@@ -30,7 +30,7 @@ Another difference is that no security is enforced on `libvirt-coreos` at all. F
* Kubernetes secrets are not protected as securely as they are on production environments;
* etc.
So, an k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like:
So, a k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like:
* un-authenticated access to Kube API server;
* Access to Kubernetes private data structures inside etcd;
@@ -45,7 +45,7 @@ On the other hand, `libvirt-coreos` might be useful for people investigating low
3. Install [qemu](http://wiki.qemu.org/Main_Page)
4. Install [libvirt](http://libvirt.org/)
5. Install [openssl](http://openssl.org/)
6. Enable and start the libvirt daemon, e.g:
6. Enable and start the libvirt daemon, e.g.:
* ``systemctl enable libvirtd && systemctl start libvirtd`` # for systemd-based systems
* ``/etc/init.d/libvirt-bin start`` # for init.d-based systems
7. [Grant libvirt access to your user¹](https://libvirt.org/aclpolkit.html)
docs/getting-started-guides/logging.md
+1 -1
View File
@@ -79,7 +79,7 @@ root 479 0.0 0.0 4348 812 ? S 00:05 0:00 sleep 1
root 480 0.0 0.0 15572 2212 ? R 00:05 0:00 ps aux
```
What happens if for any reason the image in this pod is killed off and then restarted by Kubernetes? Will we still see the log lines from the previous invocation of the container followed by the log lines for the started container? Or will we lose the log lines from the original container's execution and only see the log lines for the new container? Let’s find out. First let's delete the currently running counter.
What happens if for any reason the image in this pod is killed off and then restarted by Kubernetes? Will we still see the log lines from the previous invocation of the container followed by the log lines for the started container? Or will we lose the log lines from the original container's execution and only see the log lines for the new container? Let's find out. First let's delete the currently running counter.
```shell
$ kubectl delete pod counter
docs/getting-started-guides/meanstack.md
+12 -12
View File
@@ -17,12 +17,12 @@ Thankfully, there is a system we can use to manage our containers in a cluster e
## The Basics of Using Kubernetes
Before we jump in and start kube’ing it up, it’s important to understand some of the fundamentals of Kubernetes.
Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes.
* Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly.
* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let’s say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database.
* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database.
* Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones.
* Services: A service is the single point of contact for a group of Pods. For example, let’s say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it’s a good idea to use Services.
* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services.
## Step 1: Creating the Container
@@ -37,7 +37,7 @@ To do this, you need to use more Docker. Make sure you have the latest version i
Getting the code:
Before starting, let’s get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial.
Before starting, let's get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial.
```shell
$ git clone https://github.com/ijason/NodeJS-Sample-App.git app
@@ -45,7 +45,7 @@ $ mv app/EmployeeDB/* app/
$ sed -i -- 's/localhost/mongo/g' ./app/app.js
```
This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it’s easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy.
This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it's easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy.
Building the Docker image:
@@ -83,7 +83,7 @@ $ ls
Dockerfile app
```
Let’s build.
Let's build.
```shell
$ docker build -t myapp .
@@ -139,7 +139,7 @@ After some time, it will finish. You can check the console to see the container
## **Step 4: Creating the Cluster**
So now you have the custom container, let’s create a cluster to run it.
So now you have the custom container, let's create a cluster to run it.
Currently, a cluster can be as small as one machine to as big as 100 machines. You can pick any machine type you want, so you can have a cluster of a single `f1-micro` instance, 100 `n1-standard-32` instances (3,200 cores!), and anything in between.
@@ -193,7 +193,7 @@ $ gcloud compute disks create \
Pick the same zone as your cluster and an appropriate disk size for your application.
Now, we need to create a Deployment that will run the database. I’m using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically.
Now, we need to create a Deployment that will run the database. I'm using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically.
### `db-deployment.yml`
@@ -231,7 +231,7 @@ We call the deployment `mongo-deployment`, specify one replica, and open the app
The `volumes` section creates the volume for Kubernetes to use. There is a Google Container Engine-specific `gcePersistentDisk` section that maps the disk we made into a Kubernetes volume, and we mount the volume into the `/data/db` directory (as described in the MongoDB Docker documentation)
Now we have the Deployment, let’s create the Service:
Now we have the Deployment, let's create the Service:
### `db-service.yml`
@@ -267,7 +267,7 @@ db-service.yml
## Step 6: Running the Database
First, let’s "log in" to the cluster
First, let's "log in" to the cluster
```shell
$ gcloud container clusters get-credentials mean-cluster
@@ -305,14 +305,14 @@ mongo-deployment-xxxx 1/1 Running 0 3m
## Step 7: Creating the Web Server
Now the database is running, let’s start the web server.
Now the database is running, let's start the web server.
We need two things:
1. Deployment to spin up and down web server pods
2. Service to expose our website to the interwebs
Let’s look at the Deployment configuration:
Let's look at the Deployment configuration:
### `web-deployment.yml`
docs/getting-started-guides/mesos/index.md
+1 -1
View File
@@ -229,7 +229,7 @@ We assume that kube-dns will use
Note that we have passed these two values already as parameter to the apiserver above.
A template for an replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file:
A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file:
- replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1`
- replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.`
docs/getting-started-guides/minikube.md
+3 -3
View File
@@ -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
docs/getting-started-guides/network-policy/calico.md
+1 -1
View File
@@ -31,4 +31,4 @@ There are two main components to be aware of:
- One `calico-node` Pod runs on each node in your cluster, and enforces network policy on the traffic to/from Pods on that machine by configuring iptables.
- The `calico-policy-controller` Pod reads policy and label information from the Kubernetes API and configures Calico appropriately.
Once your cluster is running, you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
docs/getting-started-guides/network-policy/weave.md
+1 -1
View File
@@ -8,4 +8,4 @@ The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for K
This component automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces, and configures `iptables` rules to allow or block traffic as directed by the policies.
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
docs/getting-started-guides/photon-controller.md
+1 -1
View File
@@ -163,7 +163,7 @@ balancer. Specifically:
Configure your service with the NodePort option. For example, this
service uses the NodePort option. All Kubernetes nodes will listen on
a port and forward network traffic to any pods in the service. In this
case, Kubernets will choose a random port, but it will be the same
case, Kubernetes will choose a random port, but it will be the same
port on all nodes.
```yaml
docs/getting-started-guides/rackspace.md
+1 -1
View File
@@ -45,7 +45,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo
1. A cloud network will be created and all instances will be attached to this network.
- flanneld uses this network for next hop routing. These routes allow the containers running on each node to communicate with one another on this private network.
2. A SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password).
2. An SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password).
3. The master server and additional nodes will be created via the `nova` CLI. A `cloud-config.yaml` is generated and provided as user-data with the entire configuration for the systems.
4. We then boot as many nodes as defined via `$NUM_NODES`.
docs/getting-started-guides/scratch.md
+3 -3
View File
@@ -69,7 +69,7 @@ accomplished in two ways:
- **Using an overlay network**
- An overlay network obscures the underlying network architecture from the
pod network through traffic encapsulation (e.g vxlan).
pod network through traffic encapsulation (e.g. vxlan).
- Encapsulation reduces performance, though exactly how much depends on your solution.
- **Without an overlay network**
- Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses.
@@ -180,7 +180,7 @@ we recommend that you run these as containers, so you need an image to be built.
You have several choices for Kubernetes images:
- Use images hosted on Google Container Registry (GCR):
- e.g `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
- e.g. `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
release tag, which can be found on the [latest releases page](https://github.com/kubernetes/kubernetes/releases/latest).
- Ensure $TAG is the same tag as the release tag you are using for kubelet and kube-proxy.
- The [hyperkube](https://releases.k8s.io/{{page.githubbranch}}/cmd/hyperkube) binary is an all in one binary
@@ -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
docs/getting-started-guides/ubuntu/automated.md
+2 -2
View File
@@ -93,7 +93,7 @@ Note that each controller can host multiple Kubernetes clusters in a given cloud
## Launch a Kubernetes cluster
The following command will deploy the intial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but
The following command will deploy the initial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but
```shell
juju deploy canonical-kubernetes
@@ -206,7 +206,7 @@ Congratulations, you've now set up a Kubernetes cluster!
Want larger Kubernetes nodes? It is easy to request different sizes of cloud
resources from Juju by using **constraints**. You can increase the amount of
CPU or memory (RAM) in any of the systems requested by Juju. This allows you
to fine tune th Kubernetes cluster to fit your workload. Use flags on the
to fine tune the Kubernetes cluster to fit your workload. Use flags on the
bootstrap command or as a separate `juju constraints` command. Look to the
[Juju documentation for machine](https://jujucharms.com/docs/2.0/charms-constraints)
details.
docs/getting-started-guides/ubuntu/calico.md
+1 -1
View File
@@ -385,7 +385,7 @@ On your compute nodes, it is important that you install Calico before Kubernetes
## Configure kubectl remote access
To administer your cluster from a separate host (e.g your laptop), you will need the root CA generated earlier, as well as an admin public/private keypair (`ca.pem`, `admin.pem`, `admin-key.pem`). Run the following steps on the machine which you will use to control your cluster.
To administer your cluster from a separate host (e.g. your laptop), you will need the root CA generated earlier, as well as an admin public/private keypair (`ca.pem`, `admin.pem`, `admin-key.pem`). Run the following steps on the machine which you will use to control your cluster.
1. Download the kubectl binary.
docs/getting-started-guides/ubuntu/manual.md
+8 -8
View File
@@ -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.
@@ -122,7 +122,7 @@ through `FLANNEL_BACKEND` and `FLANNEL_OTHER_NET_CONFIG`, as explained in `clust
The default setting for `ADMISSION_CONTROL` is right for the latest
release of Kubernetes, but if you choose an earlier release then you
might want a different setting. See
[the admisson control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use)
[the admission control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use)
for the recommended settings for various releases.
**Note:** When deploying, master needs to be connected to the Internet to download the necessary files.
@@ -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.
docs/getting-started-guides/vsphere.md
+94 -18
View File
@@ -5,19 +5,95 @@ assignees:
title: VMware vSphere
---
The example below creates a Kubernetes cluster with 4 worker node Virtual
Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This
cluster is set up and controlled from your workstation (or wherever you find
convenient).
This page covers how to get started with deploying Kubernetes on vSphere and details for how to configure the vSphere Cloud Provider.
* TOC
{:toc}
### Prerequisites
### Getting started with vSphere
1. You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license).
2. You must have Go (see [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org).
3. You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`.
Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere).
This page also describes how to configure and get started with the cloud provider if deploying using custom install scripts.
### Deploy Kubernetes on vSphere
To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch.
Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/README.md)
### vSphere Cloud Provider
vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. It supports:
1. Volumes
2. Persistent Volumes
3. Storage Classes and provisioning of volumes.
Documentation for how to use vSphere managed storage can be found in the
[persistent volumes user
guide](http://kubernetes.io/docs/user-guide/persistent-volumes/#vsphere) and the
[volumes user
guide](http://kubernetes.io/docs/user-guide/volumes/#vspherevolume)
Examples can be found
[here](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/vsphere)
#### Configuring vSphere Cloud Provider
If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to use the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment.
* Enable UUID for a VM
This can be done via [govc tool](https://github.com/vmware/govmomi/tree/master/govc)
```
export GOVC_URL=<IP/URL>
export GOVC_USERNAME=<vCenter User>
export GOVC_PASSWORD=<vCenter Password>
export GOVC_INSECURE=1
govc vm.change -e="disk.enableUUID=1" -vm=<VMNAME>
```
* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=<path to file>``` flag. Cloud config [template can be found at Kubernetes-Anywhere] (https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf)
Sample Config:
```
[Global]
user = <User name for vCenter>
password = <Password for vCenter>
server = <IP/URL for vCenter>
port = <Default 443 for vCenter>
insecure-flag = <set to 1 if the host above uses a self-signed cert>
datacenter = <Datacenter to be used>
datastore = <Datastore to use for provisioning volumes using storage classes/dynamic provisioning>
working-dir = <Folder in which VMs are provisioned, can be null>
[Disk]
scsicontrollertype = pvscsi
```
* Set the cloud provider via ```--cloud-provider=vsphere``` flag for each instance of kubelet, apiserver and controller manager.
#### Known issues
* [Volumes are not removed from a VM configuration if the VM is down](https://github.com/kubernetes/kubernetes/issues/33061). The workaround is to manually remove the disk from VM settings before powering it up.
* [FS groups are not supported in 1.4.7](https://github.com/kubernetes/kubernetes/issues/34039)
### Kube-up (Deprecated)
Kube-up.sh is no longer supported and is deprecated. The steps for kube-up are included but going forward [kube-anywhere](https://github.com/kubernetes/kubernetes-anywhere) is preferred.
The recommended version for kube-up is [v1.4.7](https://github.com/kubernetes/kubernetes/releases/tag/v1.4.7)
The example below creates a Kubernetes cluster with 4 worker node Virtual.
Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
#### Prerequisites
* You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license).
* You must have Go (see [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org).
* You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`.
```shell
export GOPATH=$HOME/src/go
@@ -25,7 +101,7 @@ mkdir -p $GOPATH
export PATH=$PATH:$GOPATH/bin
```
4. Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest.
* Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest.
```shell
# Sample commands for v0.8.0 for 64 bit Linux.
@@ -35,9 +111,9 @@ chmod +x govc_linux_amd64
mv govc_linux_amd64 /usr/local/bin/govc
```
5. Get or build a [binary release](/docs/getting-started-guides/binary_release)
* Get or build a [binary release](/docs/getting-started-guides/binary_release)
### Setup
#### Setup
Download a prebuilt Debian 8.2 VMDK that we'll use as a base image:
@@ -91,8 +167,8 @@ Verify that the VMDK was correctly uploaded and expanded to ~3GiB:
govc datastore.ls ./kube/
```
If you need to debug any part of the deployment, the guest login for
the image that you imported is `kube:kube`. It is normally specified
If you need to debug any part of the deployment, the guest login for
the image that you imported is `kube:kube`. It is normally specified
in the GOVC_GUEST_LOGIN parameter above.
Also take a look at the file `cluster/vsphere/config-default.sh` and
@@ -100,19 +176,19 @@ make any needed changes. You can configure the number of nodes
as well as the IP subnets you have made available to Kubernetes, pods,
and services.
### Starting a cluster
#### Starting a cluster
Now, let's continue with deploying Kubernetes.
This process takes about ~20-30 minutes depending on your network.
#### From extracted binary release
##### From extracted binary release
```shell
cd kubernetes
KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh
```
#### Build from source
##### Build from source
```shell
cd kubernetes
@@ -126,7 +202,7 @@ deployment works just as any other one!
**Enjoy!**
### Extra: debugging deployment failure
#### Extra: debugging deployment failure
The output of `kube-up.sh` displays the IP addresses of the VMs it deploys. You
can log into any VM as the `kube` user to poke around and figure out what is
@@ -138,7 +214,7 @@ going on (find yourself authorized with your SSH key, or use the password
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Vmware vSphere | Saltstack | Debian | OVS | [docs](/docs/getting-started-guides/vsphere) | | Community ([@imkin](https://github.com/imkin)), ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@kerneltime](https://github.com/luomiao))
Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu))([@luomiao](https://github.com/luomiao))
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
docs/getting-started-guides/windows/index.md
+4 -4
View File
@@ -15,18 +15,18 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported
4. Docker Version 1.12.2-cs2-ws-beta or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version)
## Networking
Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used.
Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don't natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used.
### Linux
The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the “public” NIC.
The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC.
### Windows
Each Window Server node should have the following configuration:
1. Two NICs (virtual networking adapters) are required on each Windows Server node - The two Windows container networking modes of interest (transparent and L2 bridge) use an external Hyper-V virtual switch. This means that one of the NICs is entirely allocated to the bridge, creating the need for the second NIC.
2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below
3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also “captures” packets that have the destination IP of a POD running on the node. To enable, open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Routing and Remote Access Service” and the underlying checkboxes
4. Routes defined pointing to the other pod CIDRs via the “public” NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below
3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes
4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below
The following diagram illustrates the Windows Server networking setup for Kubernetes Setup
![Windows Setup](windows-setup.png)
docs/hellonode.md
+11 -11
View File
@@ -12,7 +12,7 @@ title: Hello World on Google Container Engine
The goal of this codelab is for you to turn a simple Hello World node.js app into a replicated application running on Kubernetes. We will show you how to take code that you have developed on your machine, turn it into a Docker container image, and then run that image on [Google Container Engine](https://cloud.google.com/container-engine/).
Here’s a diagram of the various parts in play in this codelab to help you understand how pieces fit with one another. Use this as a reference as we progress through the codelab; it should all make sense by the time we get to the end.
Here's a diagram of the various parts in play in this codelab to help you understand how pieces fit with one another. Use this as a reference as we progress through the codelab; it should all make sense by the time we get to the end.
![image](/images/hellonode/image_1.png)
@@ -38,7 +38,7 @@ export PROJECT_ID="your-project-id"
Next, [enable billing](https://console.cloud.google.com/billing) in the Cloud Console in order to use Google Cloud resources and [enable the Container Engine API](https://console.cloud.google.com/project/_/kubernetes/list).
New users of Google Cloud Platform receive a [$300 free trial](https://console.cloud.google.com/billing/freetrial?hl=en). Running through this codelab shouldn’t cost you more than a few dollars of that trial. Google Container Engine pricing is documented [here](https://cloud.google.com/container-engine/pricing).
New users of Google Cloud Platform receive a [$300 free trial](https://console.cloud.google.com/billing/freetrial?hl=en). Running through this codelab shouldn't cost you more than a few dollars of that trial. Google Container Engine pricing is documented [here](https://cloud.google.com/container-engine/pricing).
Next, make sure you [download Node.js](https://nodejs.org/en/download/). You can skip this and the steps for installing Docker and Cloud SDK if you're using Cloud Shell.
@@ -79,7 +79,7 @@ You should be able to see your "Hello World!" message at http://localhost:8080/.
Stop the running node server by pressing Ctrl-C.
Now let’s package this application in a Docker container.
Now let's package this application in a Docker container.
## Create a Docker container image
@@ -109,7 +109,7 @@ Let's try your image out with Docker:
docker run -d -p 8080:8080 --name hello_tutorial gcr.io/$PROJECT_ID/hello-node:v1
```
Visit your app in the browser, or use `curl` or `wget` if you’d like :
Visit your app in the browser, or use `curl` or `wget` if you'd like :
```shell
curl http://localhost:8080
@@ -123,7 +123,7 @@ You should see `Hello World!`
curl "http://$(docker-machine ip YOUR-VM-MACHINE-NAME):8080"
```
Let’s now stop the container. You can list the docker containers with:
Let's now stop the container. You can list the docker containers with:
```shell
docker ps
@@ -180,7 +180,7 @@ You should get a Kubernetes cluster with three nodes, ready to receive your cont
![image](/images/hellonode/image_11.png)
It’s now time to deploy your own containerized application to the Kubernetes cluster!
It's now time to deploy your own containerized application to the Kubernetes cluster!
```shell
gcloud container clusters get-credentials hello-world
@@ -258,7 +258,7 @@ kubectl expose deployment hello-node --type="LoadBalancer"
**If this fails, make sure your client and server are both version 1.3. See the [Create your cluster](#create-your-cluster) section for details.**
The flag used in this command specifies that we’ll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). Note that we expose the deployment, and not the pod directly. This will cause the resulting service to load balance traffic across all pods managed by the deployment (in this case only 1 pod, but we will add more replicas later).
The flag used in this command specifies that we'll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). Note that we expose the deployment, and not the pod directly. This will cause the resulting service to load balance traffic across all pods managed by the deployment (in this case only 1 pod, but we will add more replicas later).
The Kubernetes master creates the load balancer and related Compute Engine forwarding rules, target pools, and firewall rules to make the service fully accessible from outside of Google Cloud Platform.
@@ -322,7 +322,7 @@ hello-node-714049816-ztzrb 1/1 Running 0 41m
Note the **declarative approach** here - rather than starting or stopping new instances you declare how many instances you want to be running. Kubernetes reconciliation loops simply make sure the reality matches what you requested and take action if needed.
Here’s a diagram summarizing the state of our Kubernetes cluster:
Here's a diagram summarizing the state of our Kubernetes cluster:
![image](/images/hellonode/image_13.png)
@@ -330,7 +330,7 @@ Here’s a diagram summarizing the state of our Kubernetes cluster:
As always, the application you deployed to production requires bug fixes or additional features. Kubernetes is here to help you deploy a new version to production without impacting your users.
First, let’s modify the application. On the development machine, edit server.js and update the response message:
First, let's modify the application. On the development machine, edit server.js and update the response message:
```javascript
response.end('Hello Kubernetes World!');
@@ -345,7 +345,7 @@ gcloud docker -- push gcr.io/$PROJECT_ID/hello-node:v2
Building and pushing this updated image should be much quicker as we take full advantage of the Docker cache.
We’re now ready for Kubernetes to smoothly update our deployment to the new version of the application. In order to change
We're now ready for Kubernetes to smoothly update our deployment to the new version of the application. In order to change
the image label for our running container, we will need to edit the existing *hello-node deployment* and change the image from
`gcr.io/$PROJECT_ID/hello-node:v1` to `gcr.io/$PROJECT_ID/hello-node:v2`. To do this, we will use the `kubectl set image` command.
@@ -364,7 +364,7 @@ hello-node 4 5 4 3 1h
While this is happening, the users of the services should not see any interruption. After a little while they will start accessing the new version of your application. You can find more details in the [deployment documentation](/docs/user-guide/deployments/).
Hopefully with these deployment, scaling and update features you’ll agree that once you’ve setup your environment (your GKE/Kubernetes cluster here), Kubernetes is here to help you focus on the application rather than the infrastructure.
Hopefully with these deployment, scaling and update features you'll agree that once you've setup your environment (your GKE/Kubernetes cluster here), Kubernetes is here to help you focus on the application rather than the infrastructure.
## Observe the Kubernetes Web UI (optional)
docs/reporting-security-issues.md
+1 -21
View File
@@ -5,24 +5,4 @@ assignees:
title: Report a Security Vulnerability
---
If you believe you have discovered a vulnerability or a have a security incident to report, please follow the steps below. This applies to Kubernetes releases v1.0 or later.
To watch for security and major API announcements, please join our [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group.
## Reporting a security issue
To report an issue, please:
- Submit a bug report [here](http://goo.gl/vulnz).
- Select 'I want to report a technical security bug in a Google product (SQLi, XSS, etc.).'?
- Select 'Other'? as the Application Type.
- Under reproduction steps, please additionally include
- the words "Kubernetes Security issue"
- Description of the issue
- Kubernetes release (e.g. output of `kubectl version` command, which includes server version.)
- Environment setup (e.g. which "Getting Started Guide" you followed, if any; what node operating system used; what service or software creates your virtual machines, if any)
An online submission will have the fastest response; however, if you prefer email, please send mail to security@google.com. If you feel the need, please use the [PGP public key](https://services.google.com/corporate/publickey.txt) to encrypt communications.
This document has moved to [http://kubernetes.io/security](http://kubernetes.io/security).
docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
+1 -1
View File
@@ -52,7 +52,7 @@ load-balanced access to an application running in a cluster.
NAME DESIRED CURRENT AGE
hello-world-2189936611 2 2 12m
1. Create a Serivice object that exposes the replica set:
1. Create a Service object that exposes the replica set:
kubectl expose rs <your-replica-set-name> --type="LoadBalancer" --name="example-service"
docs/tasks/administer-cluster/safely-drain-node.md
+3
View File
@@ -44,11 +44,13 @@ down its physical machine or, if running on a cloud platform, deleting its
virtual machine.
First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with
```shell
kubectl get nodes
```
Next, tell Kubernetes to drain the node:
```shell
kubectl drain <node name>
```
@@ -56,6 +58,7 @@ kubectl drain <node name>
Once it returns (without giving an error), you can power down the node
(or equivalently, if on a cloud platform, delete the virtual machine backing the node).
If you leave the node in the cluster during the maintenance operation, you need to run
```shell
kubectl uncordon <node name>
```
docs/tasks/manage-stateful-set/deleting-a-statefulset.md
+1 -1
View File
@@ -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>
docs/tools/index.md
+12 -10
View File
@@ -4,29 +4,31 @@ assignees:
title: Tools
---
* TOC
{:toc}
Kubernetes contains several built-in tools to help you work with the Kubernetes system, and also supports third-party tooling.
## Native Tools
#### Native Tools
### Kubectl
Kubernetes contains the following built-in tools:
##### Kubectl
[`kubectl`](/docs/user-guide/kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
### Kubefed
##### Kubefed
[`kubefed`](/docs/admin/federation/kubefed/) is the command line tool
to help you administrate your federated clusters.
### Dashboard
##### Dashboard
[Dashboard](/docs/user-guide/ui/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
## Third-Party Tools
#### Third-Party Tools
### Helm
Kubernetes supports various third-party tools. These include, but are not limited to:
##### Helm
[Kubernetes Helm](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
Kubernetes resources, aka Kubernetes charts.
@@ -39,7 +41,7 @@ Use Helm to:
* Intelligently manage your Kubernetes manifest files
* Manage releases of Helm packages
### Kompose
##### Kompose
[Kompose](https://github.com/kubernetes-incubator/kompose) is a tool to help users familiar with Docker Compose
move to Kubernetes.
docs/troubleshooting.md
+1 -1
View File
@@ -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
docs/tutorials/kubernetes-basics/cluster-intro.html
+1 -1
View File
@@ -90,7 +90,7 @@ title: Using Minikube to Create a Cluster
<p>A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use <a href="https://github.com/kubernetes/minikube">Minikube</a>. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, Mac OS and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this bootcamp, however, you'll use a provided online terminal with Minikube pre-installed.</p>
<p>Now that you know what Kubernetes is, let’s go to the online tutorial and start our first cluster!</p>
<p>Now that you know what Kubernetes is, let's go to the online tutorial and start our first cluster!</p>
</div>
</div>
docs/tutorials/kubernetes-basics/deploy-intro.html
+2 -2
View File
@@ -86,9 +86,9 @@ title: Using kubectl to Create a Deployment
<div class="row">
<div class="col-md-8">
<p>For our first Deployment, we’ll use a <a href="https://nodejs.org">Node.js</a> application packaged in a Docker container. The source code and the Dockerfile are available in the <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub repository</a> for the Kubernetes Bootcamp.</p>
<p>For our first Deployment, we'll use a <a href="https://nodejs.org">Node.js</a> application packaged in a Docker container. The source code and the Dockerfile are available in the <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub repository</a> for the Kubernetes Bootcamp.</p>
<p>Now that you know what Deployments are, let’s go to the online tutorial and deploy our first app!</p>
<p>Now that you know what Deployments are, let's go to the online tutorial and deploy our first app!</p>
</div>
</div>
docs/tutorials/kubernetes-basics/explore-intro.html
+2 -2
View File
@@ -34,7 +34,7 @@ title: Viewing Pods and Nodes
<li>Networking, as a unique cluster IP address</li>
<li>Information about how to run each container, such as the container image version or specific ports to use</li>
</ul>
<p>A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.</p>
<p>A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.</p>
<p>Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.</p>
@@ -117,7 +117,7 @@ title: Viewing Pods and Nodes
<p>You can use these commands to see when applications were deployed, what their current statuses are, where they are running and what their configurations are.</p>
<p>Now that we know more about our cluster components and the command line, let’s explore our application.</p>
<p>Now that we know more about our cluster components and the command line, let's explore our application.</p>
</div>
<div class="col-md-4">
docs/tutorials/kubernetes-basics/expose-intro.html
+4 -4
View File
@@ -28,11 +28,11 @@ title: Using a Service to Expose Your App
<div class="col-md-8">
<h3>Kubernetes Services</h3>
<p>While Pods do have their own unique IP across the cluster, those IP’s are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes <b>Service</b> is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</p>
<p>While Pods do have their own unique IP across the cluster, those IP's are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes <b>Service</b> is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</p>
<p>This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:</p>
<ul>
<li>LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GKE or AWS)</li>
<li>LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GCP or AWS)</li>
<li>NodePort - exposes the Service on the same port on each Node of the cluster using NAT (available on all Kubernetes clusters, and in Minikube)</li>
</ul>
</div>
@@ -70,7 +70,7 @@ title: Using a Service to Expose Your App
<div class="row">
<div class="col-md-8">
<p>A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we’ll have multiple instances running).</p>
<p>A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we'll have multiple instances running).</p>
<p>Services are also responsible for service-discovery within the cluster (covered in <a href="/docs/user-guide/connecting-applications/#accessing-the-service">Accessing the Service</a>). This will for example allow a frontend service (like a web server) to receive traffic from a backend service (like a database) without worrying about Pods.</p>
@@ -120,7 +120,7 @@ title: Using a Service to Expose Your App
<p>Labels can be attached to objects at the creation time or later and can be modified at any time.
The kubectl run command sets some default Labels/Label Selectors on the new Pods/ Deployment. The link between Labels and Label Selectors defines the relationship between the Deployment and the Pods it creates.</p>
<p>Now let’s expose our application with the help of a Service, and apply some new Labels.</p>
<p>Now let's expose our application with the help of a Service, and apply some new Labels.</p>
</div>
</div>
<br>
docs/tutorials/kubernetes-basics/scale-intro.html
+1 -1
View File
@@ -101,7 +101,7 @@ title: Running Multiple Instances of Your App
<div class="row">
<div class="col-md-8">
<p> Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime. We’ll cover that in the next module. Now, let’s go to the online terminal and scale our application.</p>
<p> Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime. We'll cover that in the next module. Now, let's go to the online terminal and scale our application.</p>
</div>
</div>
<br>
docs/tutorials/kubernetes-basics/update-intro.html
+1 -1
View File
@@ -116,7 +116,7 @@ title: Performing a Rolling Update
<div class="row">
<div class="col-md-8">
<p> In the following interactive tutorial we’ll update our application to a new version, and also perform a rollback.</p>
<p> In the following interactive tutorial we'll update our application to a new version, and also perform a rollback.</p>
</div>
</div>
<br>
docs/tutorials/services/source-ip.md
+1 -1
View File
@@ -29,7 +29,7 @@ This document makes use of the following terms:
You must have a working Kubernetes 1.5 cluster to run the examples in this
document. The examples use a small nginx webserver that echoes back the source
IP of requests it receives through a HTTP header. You can create it as follows:
IP of requests it receives through an HTTP header. You can create it as follows:
```console
$ kubectl run source-ip-app --image=gcr.io/google_containers/echoserver:1.4
docs/tutorials/stateful-application/basic-stateful-set.md
+5 -5
View File
@@ -11,7 +11,7 @@ title: StatefulSet Basics
---
{% capture overview %}
This tutorial provides an introduction to managing applications with
This tutorial provides an introduction to manage applications with
[StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/). It
demonstrates how to create, delete, scale, and update the container image of a
StatefulSet.
@@ -77,7 +77,7 @@ In the second terminal, use
Headless Service and StatefulSet defined in `web.yaml`.
```shell
kubectl create -f web.yml
kubectl create -f web.yaml
service "nginx" created
statefulset "web" created
```
@@ -122,7 +122,7 @@ launching `web-1`. In fact, `web-1` is not launched until `web-0` is
[Running and Ready](/docs/user-guide/pod-states).
### Pods in a StatefulSet
Unlike Pods in other controllers, the Pods in a StatefulSet have a unqiue
Unlike Pods in other controllers, the Pods in a StatefulSet have a unique
ordinal index and a stable network identity.
#### Examining the Pod's Ordinal Index
@@ -177,7 +177,7 @@ Name: web-1.nginx
Address 1: 10.244.2.6
```
The CNAME of the headless serivce points to SRV records (one for each Pod that
The CNAME of the headless service points to SRV records (one for each Pod that
is Running and Ready). The SRV records point to A record entries that
contain the Pods' IP addresses.
@@ -733,4 +733,4 @@ storage configuration, and provisioning method, to ensure that all storage is
reclaimed.
{% endcapture %}
{% include templates/tutorial.md %}
{% include templates/tutorial.md %}
docs/tutorials/stateful-application/run-replicated-stateful-application.md
+1 -1
View File
@@ -180,7 +180,7 @@ replicating.
In general, when a new Pod joins the set as a slave, it must assume the MySQL
master might already have data on it. It also must assume that the replication
logs might not go all the way back to the beginning of time.
These conservative assumptions are the key to allowing a running StatefulSet
These conservative assumptions are the key to allow a running StatefulSet
to scale up and down over time, rather than being fixed at its initial size.
The second Init Container, named `clone-mysql`, performs a clone operation on
docs/tutorials/stateful-application/zookeeper.md
+2 -2
View File
@@ -173,7 +173,7 @@ zk-2
```
The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and
each server's identifier is stored in a file called `myid` in the server’s
each server's identifier is stored in a file called `myid` in the server's
data directory.
Examine the contents of the `myid` file for each server.
@@ -799,7 +799,7 @@ Examine the process tree for the ZooKeeper server running in the `zk-0` Pod.
kubectl exec zk-0 -- ps -ef
```
The command used as the container's entry point has PID 1, and the
The command used as the container's entry point has PID 1, and
the ZooKeeper process, a child of the entry point, has PID 23.
docs/tutorials/stateless-application/Dockerfile
+4
View File
@@ -0,0 +1,4 @@
FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js
docs/tutorials/stateless-application/expose-external-ip-address.md
+1 -1
View File
@@ -4,7 +4,7 @@ title: Exposing an External IP Address to Access an Application in a Cluster
{% capture overview %}
This page shows how to create a Kubernetes Service object that exposees an
This page shows how to create a Kubernetes Service object that exposes an
external IP address.
{% endcapture %}
docs/tutorials/stateless-application/hello-minikube.md
+305
View File
@@ -0,0 +1,305 @@
{% capture overview %}
The goal of this tutorial is for you to turn a simple Hello World Node.js app
into an application running on Kubernetes. The tutorial shows you how to
take code that you have developed on your machine, turn it into a Docker
container image and then run that image on [Minikube](/docs/getting-started-guides/minikube).
Minikube provides a simple way of running Kubernetes on your local machine for free.
{% endcapture %}
{% capture objectives %}
* Run a hello world Node.js application.
* Deploy the application to Minikube.
* View application logs.
* Update the application image.
{% endcapture %}
{% capture prerequisites %}
* For OS X, you need [Homebrew](https://brew.sh) to install the `xhyve`
driver.
* [NodeJS](https://nodejs.org/en/) is required to run the sample application.
* Install Docker. On OS X, we recommend
[Docker for Mac](https://docs.docker.com/engine/installation/mac/).
{% endcapture %}
{% capture lessoncontent %}
### Create a Minikube cluster
This tutorial uses [Minikube](https://github.com/kubernetes/minikube) to
create a local cluster. This tutorial also assumes you are using
[Docker for Mac](https://docs.docker.com/engine/installation/mac/)
on OS X. If you are on a different platform like Linux, or using VirtualBox
instead of Docker for Mac, the instructions to install Minikube may be
slightly different. For general Minikube installation instructions, see
the [Minikube installation guide](docs/getting-started-guides/minikube/).
Use `curl` to download and install the latest Minikube release:
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
```
Use Homebrew to install the xhyve driver and set its permissions:
```shell
brew install docker-machine-driver-xhyve
sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
```
Download the latest version of the `kubectl` command-line tool, which you can
use to interact with Kubernetes clusters:
```shell
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
```
Start the Minikube cluster:
```shell
minikube start --vm-driver=xhyve
```
The `--vm-driver=xyhve` flag specifies that you are using Docker for Mac. The
default VM driver is VirtualBox.
Now set the Minikube context. The context is what determines which cluster
`kubectl` is interacting with. You can see all your available contexts in the
`~/.kube/config` file.
```shell
kubectl config use-context minikube
```
Verify that `kubectl` is configured to communicate with your cluster:
```shell
kubectl cluster-info
```
### Create your Node.js application
The next step is to write the application. Save this code in a folder named `hellonode`
with the filename `server.js`:
{% include code.html language="js" file="server.js" ghlink="docs/tutorials/stateless-application/server.js" %}
Run your application:
```shell
node server.js
```
You should be able to see your "Hello World!" message at http://localhost:8080/.
Stop the running Node.js server by pressing **Ctrl-C**.
The next step is to package your application in a Docker container.
### Create a Docker container image
Create a file, also in the `hellonode` folder, named `Dockerfile`. A Dockerfile describes
the image that you want to build. You can build a Docker container image by extending an
existing image. The image in this tutorial extends an existing Node.js image.
{% include code.html language="conf" file="Dockerfile" ghlink="/docs/tutorials/stateless-application/Dockerfile" %}
This recipe for the Docker image starts from the official Node.js LTS image
found in the Docker registry, exposes port 8080, copies your `server.js` file
to the image and start the Node.js server.
Because this tutorial uses Minikube, instead of pushing your Docker image to a
registry, you can simply build the image using the same Docker host as
the Minikube VM, so that the images are automatically present. To do so, make
sure you are using the Minikube Docker daemon:
```shell
eval $(minikube docker-env)
```
**Note:** Later, when you no longer wish to use the Minikube host, you can undo
this change by running `eval $(minikube docker-env) -u`.
Build your Docker image, using the Minikube Docker daemon:
```shell
docker build -t hello-node:v1 .
```
Now the Minikube VM can run the image you built.
### Create a Deployment
A Kubernetes [*Pod*](/docs/user-guide/pods/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/user-guide/deployments) checks on the health of your
Pod and restarts the Pod's Container if it terminates. Deployments are the
recommended way to manage the creation and scaling of Pods.
Use the `kubectl run` command to create a Deployment that manages a Pod. The
Pod runs a Container based on your `hello-node:v1` Docker image:
```shell
kubectl run hello-node --image=hello-node:v1 --port=8080
```
View the Deployment:
```shell
kubectl get deployments
```
Output:
```shell
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
hello-node 1 1 1 1 3m
```
View the Pod:
```shell
kubectl get pods
```
Output:
```shell
NAME READY STATUS RESTARTS AGE
hello-node-714049816-ztzrb 1/1 Running 0 6m
```
View cluster events:
```shell
kubectl get events
```
View the `kubectl` configuration:
```shell
kubectl config view
```
For more information about `kubectl`commands, see the
[kubectl overview](/docs/user-guide/kubectl-overview/).
### Create a Service
By default, the Pod is only accessible by its internal IP address within the
Kubernetes cluster. To make the `hello-node` Container accessible from outside the
Kubernetes virtual network, you have to expose the Pod as a
Kubernetes [*Service*](/docs/user-guide/services/).
From your development machine, you can expose the Pod to the public internet
using the `kubectl expose` command:
```shell
kubectl expose deployment hello-node --type=LoadBalancer
```
View the Service you just created:
```shell
kubectl get services
```
Output:
```shell
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node 10.0.0.71 <pending> 8080/TCP 6m
kubernetes 10.0.0.1 <none> 443/TCP 14d
```
The `--type=LoadBalancer` flag indicates that you want to expose your Service
outside of the cluster. On cloud providers that support load balancers,
an external IP address would be provisioned to access the Service. On Minikube,
the `LoadBalancer` type makes the Service accessible through the `minikube service`
command.
```shell
minikube service hello-node
```
This automatically opens up a browser window using a local IP address that
serves your app and shows the "Hello World" message.
Assuming you've sent requests to your new web service using the browser or curl,
you should now be able to see some logs:
```shell
kubectl logs <POD-NAME>
```
### Update your app
Edit your `server.js` file to return a new message:
```javascript
response.end('Hello World Again!');
```
Build a new version of your image:
```shell
docker build -t hello-node:v2 .
```
Update the image of your Deployment:
```shell
kubectl set image deployment/hello-node hello-node=hello-node:v2
```
Run your app again to view the new message:
```shell
minikube service hello-node
```
### Clean up
Now you can clean up the resources you created in your cluster:
```shell
kubectl delete service hello-node
kubectl delete deployment hello-node
```
Optionally, stop Minikube:
```shell
minikube stop
```
{% endcapture %}
{% capture whatsnext %}
* Learn more about [Deployment objects](/docs/user-guide/deployments/).
* Learn more about [Deploying applications](http://localhost:4000/docs/user-guide/deploying-applications/).
* Learn more about [Service objects](/docs/user-guide/services/).
{% endcapture %}
{% include templates/tutorial.md %}
docs/tutorials/stateless-application/run-stateless-application-deployment.md
+1 -1
View File
@@ -101,7 +101,7 @@ should have four pods:
1. Verify that the Deployment has four pods:
kubectl get pods
kubectl get pods -l app=nginx
The output is similar to this:
docs/tutorials/stateless-application/server.js
+7
View File
@@ -0,0 +1,7 @@
var handleRequest = function(request, response) {
console.log('Received request for URL: ' + request.url);
response.writeHead(200);
response.end('Hello World!');
};
var www = http.createServer(handleRequest);
www.listen(8080);
docs/user-guide/accessing-the-cluster.md
+2 -3
View File
@@ -182,9 +182,8 @@ From within a pod the recommended ways to connect to API are:
Kubernetes API to the localhost interface of the pod, so that other processes
in any container of the pod can access it. See this [example of using kubectl proxy
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
- use the Go client library, and create a client using the `client.NewInCluster()` factory.
This handles locating and authenticating to the apiserver. See this [example of using Go client
library in a pod](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go).
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
They handle locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
docs/user-guide/configmap/index.md
+1 -1
View File
@@ -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
docs/user-guide/configuring-containers.md
+1 -1
View File
@@ -75,7 +75,7 @@ apiVersion: v1
kind: Pod
metadata:
name: hello-world
spec: # specification of the pod’s contents
spec: # specification of the pod's contents
restartPolicy: Never
containers:
- name: hello
docs/user-guide/connecting-applications.md
+3 -3
View File
@@ -43,7 +43,7 @@ $ kubectl get pods -l run=my-nginx -o yaml | grep podIP
podIP: 10.244.2.5
```
You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model.
You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model.
You can read more about [how we achieve this](/docs/admin/networking/#how-to-achieve-this) if you're curious.
@@ -181,7 +181,7 @@ default-token-il9rc kubernetes.io/service-account-token 1
nginxsecret Opaque 2
```
Now modify your nginx replicas to start a https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
{% include code.html language="yaml" file="nginx-secure-app.yaml" ghlink="/docs/user-guide/nginx-secure-app" %}
@@ -295,7 +295,7 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
Kubernetes also supports Federated Services, which can span multiple
clusters and cloud providers, to provide increased availability,
bettern fault tolerance and greater scalability for your services. See
better fault tolerance and greater scalability for your services. See
the [Federated Services User Guide](/docs/user-guide/federation/federated-services/)
for further information.
docs/user-guide/container-environment.md
+23 -2
View File
@@ -60,7 +60,9 @@ This hook is called immediately before a container is terminated. No parameters
### Hook Handler Execution
When a management hook occurs, the management system calls into any registered hook handlers in the container for that hook.  These hook handler calls are synchronous in the context of the pod containing the container. Typically we expect that users will make their hook handlers as lightweight as possible, but there are cases where long running commands make sense (e.g. saving state prior to container stop).
When a management hook occurs, the management system calls into any registered hook handlers in the container for that hook.  These hook handler calls are synchronous in the context of the pod containing the container. This means that for a `PostStart` hook, the container entrypoint and hook will fire asynchronously. However, if the hook takes a while to run or hangs, the container will never reach a "running" state. The behavior is similar for a `PreStop` hook. If the hook hangs during execution, the Pod phase will stay in a "running" state and never reach "failed." If a `PostStart` or `PreStop` hook fails, it will kill the container.
Typically we expect that users will make their hook handlers as lightweight as possible, but there are cases where long running commands make sense (e.g. saving state prior to container stop).
### Hook delivery guarantees
@@ -81,4 +83,23 @@ Hook handlers are the way that hooks are surfaced to containers.  Containers ca
* HTTP - Executes an HTTP request against a specific endpoint on the container.
[1]: http://man7.org/linux/man-pages/man2/gethostname.2.html
[1]: http://man7.org/linux/man-pages/man2/gethostname.2.html
### Debugging Hook Handlers
Currently, the logs for a hook handler are not exposed in the pod events. If your handler fails for some reason, it will emit an event. For `PostStart`, this is the `FailedPostStartHook` event. For `PreStop` this is the `FailedPreStopHook` event. You can see these events by running `kubectl describe pod <pod_name>`. An example output of events from runing this command is below:
```
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
docs/user-guide/cron-jobs.md
+1 -1
View File
@@ -9,7 +9,7 @@ title: Cron Jobs
* TOC
{:toc}
## What is a Cron Job?
## What is a cron job?
A _Cron Job_ manages time based [Jobs](/docs/user-guide/jobs/), namely:
docs/user-guide/debugging-services.md
+23 -23
View File
@@ -7,8 +7,8 @@ title: Debugging Services
---
An issue that comes up rather frequently for new installations of Kubernetes is
that `Services` are not working properly. You've run all your `Pod`s and
`Deployment`s, but you get no response when you try to access them.
that `Services` are not working properly. You've run all your `Pods` and
`Deployments`, but you get no response when you try to access them.
This document will hopefully help you to figure out what's going wrong.
* TOC
@@ -17,7 +17,7 @@ This document will hopefully help you to figure out what's going wrong.
## Conventions
Throughout this doc you will see various commands that you can run. Some
commands need to be run within `Pod`, others on a Kubernetes `Node`, and others
commands need to be run within a `Pod`, others on a Kubernetes `Node`, and others
can run anywhere you have `kubectl` and credentials for the cluster. To make it
clear what is expected, this document will use the following conventions.
@@ -71,7 +71,7 @@ $ kubectl exec -ti <POD-NAME> -c <CONTAINER-NAME> sh
## Setup
For the purposes of this walk-through, let's run some `Pod`s. Since you're
For the purposes of this walk-through, let's run some `Pods`. Since you're
probably debugging your own `Service` you can substitute your own details, or you
can follow along and get a second data point.
@@ -109,7 +109,7 @@ spec:
protocol: TCP
```
Confirm your `Pod`s are running:
Confirm your `Pods` are running:
```shell
$ kubectl get pods -l app=hostnames
@@ -196,7 +196,7 @@ Address: 10.0.1.175
```
If this fails, perhaps your `Pod` and `Service` are in different
`Namespace`s, try a namespace-qualified name:
`Namespaces`, try a namespace-qualified name:
```shell
u@pod$ nslookup hostnames.default
@@ -207,7 +207,7 @@ Name: hostnames.default
Address: 10.0.1.175
```
If this works, you'll need to ensure that `Pod`s and `Service`s run in the same
If this works, you'll need to ensure that `Pods` and `Services` run in the same
`Namespace`. If this still fails, try a fully-qualified name:
```shell
@@ -326,18 +326,18 @@ $ kubectl get service hostnames -o json
```
Is the port you are trying to access in `spec.ports[]`? Is the `targetPort`
correct for your `Pod`s? If you meant it to be a numeric port, is it a number
(9376) or a string "9376"? If you meant it to be a named port, do your `Pod`s
correct for your `Pods`? If you meant it to be a numeric port, is it a number
(9376) or a string "9376"? If you meant it to be a named port, do your `Pods`
expose a port with the same name? Is the port's `protocol` the same as the
`Pod`'s?
## Does the Service have any Endpoints?
If you got this far, we assume that you have confirmed that your `Service`
exists and resolves by DNS. Now let's check that the `Pod`s you ran are
exists and is resolved by DNS. Now let's check that the `Pods` you ran are
actually being selected by the `Service`.
Earlier we saw that the `Pod`s were running. We can re-check that:
Earlier we saw that the `Pods` were running. We can re-check that:
```shell
$ kubectl get pods -l app=hostnames
@@ -347,7 +347,7 @@ hostnames-bvc05 1/1 Running 0 1h
hostnames-yp2kp 1/1 Running 0 1h
```
The "AGE" column says that these `Pod`s are about an hour old, which implies that
The "AGE" column says that these `Pods` are about an hour old, which implies that
they are running fine and not crashing.
The `-l app=hostnames` argument is a label selector - just like our `Service`
@@ -360,16 +360,16 @@ NAME ENDPOINTS
hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376
```
This confirms that the control loop has found the correct `Pod`s for your
This confirms that the control loop has found the correct `Pods` for your
`Service`. If the `hostnames` row is blank, you should check that the
`spec.selector` field of your `Service` actually selects for `metadata.labels`
values on your `Pod`s.
values on your `Pods`.
## Are the Pods working?
At this point, we know that your `Service` exists and has selected your `Pod`s.
Let's check that the `Pod`s are actually working - we can bypass the `Service`
mechanism and go straight to the `Pod`s.
At this point, we know that your `Service` exists and has selected your `Pods`.
Let's check that the `Pods` are actually working - we can bypass the `Service`
mechanism and go straight to the `Pods`.
```shell
u@pod$ wget -qO- 10.244.0.5:9376
@@ -384,19 +384,19 @@ hostnames-yp2kp
We expect each `Pod` in the `Endpoints` list to return its own hostname. If
this is not what happens (or whatever the correct behavior is for your own
`Pod`s), you should investigate what's happening there. You might find
`kubectl logs` to be useful or `kubectl exec` directly to your `Pod`s and check
`Pods`), you should investigate what's happening there. You might find
`kubectl logs` to be useful or `kubectl exec` directly to your `Pods` and check
service from there.
## Is the kube-proxy working?
If you get here, your `Service` is running, has `Endpoints`, and your `Pod`s
If you get here, your `Service` is running, has `Endpoints`, and your `Pods`
are actually serving. At this point, the whole `Service` proxy mechanism is
suspect. Let's confirm it, piece by piece.
### Is kube-proxy running?
Confirm that `kube-proxy` is running on your `Node`s. You should get something
Confirm that `kube-proxy` is running on your `Nodes`. You should get something
like the below:
```shell
@@ -429,7 +429,7 @@ should double-check your `Node` configuration and installation steps.
### Is kube-proxy writing iptables rules?
One of the main responsibilities of `kube-proxy` is to write the `iptables`
rules which implement `Service`s. Let's check that those rules are getting
rules which implement `Services`. Let's check that those rules are getting
written.
The kube-proxy can run in either "userspace" mode or "iptables" mode.
@@ -620,7 +620,7 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
## Seek help
If you get this far, something very strange is happening. Your `Service` is
running, has `Endpoints`, and your `Pod`s are actually serving. You have DNS
running, has `Endpoints`, and your `Pods` are actually serving. You have DNS
working, `iptables` rules installed, and `kube-proxy` does not seem to be
misbehaving. And yet your `Service` is not working. You should probably let
us know, so we can help investigate!
docs/user-guide/deployments.md
+51 -19
View File
@@ -86,24 +86,56 @@ After creating or updating a Deployment, you would want to confirm whether it su
```shell
$ kubectl rollout status deployment/nginx-deployment
deployment nginx-deployment successfully rolled out
deployment "nginx-deployment" successfully rolled out
```
This verifies the Deployment's `.status.observedGeneration` >= `.metadata.generation`, and its up-to-date replicas
(`.status.updatedReplicas`) matches the desired replicas (`.spec.replicas`) to determine if the rollout succeeded.
If the rollout is still in progress, it watches for Deployment status changes and prints related messages.
Note that it's impossible to know whether a Deployment will ever succeed, so if the above command doesn't return success,
you'll need to timeout and give up at some point.
Additionally, if you set `.spec.minReadySeconds`, you would also want to check if the available replicas (`.status.availableReplicas`) matches the desired replicas too.
(`.status.updatedReplicas`) matches the desired replicas (`.spec.replicas`) to determine if the rollout succeeded.
It also expects that the available replicas running (`.spec.availableReplicas`) will be at least the minimum required
based on the Deployment strategy. If the rollout is still in progress, it watches for Deployment status changes and
prints related messages.
```shell
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 20s
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 10 new replicas have been updated...
Waiting for rollout to finish: 2 out of 10 new replicas have been updated...
Waiting for rollout to finish: 2 out of 10 new replicas have been updated...
Waiting for rollout to finish: 3 out of 10 new replicas have been updated...
Waiting for rollout to finish: 3 out of 10 new replicas have been updated...
Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
Waiting for rollout to finish: 5 out of 10 new replicas have been updated...
Waiting for rollout to finish: 5 out of 10 new replicas have been updated...
Waiting for rollout to finish: 5 out of 10 new replicas have been updated...
Waiting for rollout to finish: 5 out of 10 new replicas have been updated...
Waiting for rollout to finish: 6 out of 10 new replicas have been updated...
Waiting for rollout to finish: 6 out of 10 new replicas have been updated...
Waiting for rollout to finish: 6 out of 10 new replicas have been updated...
Waiting for rollout to finish: 6 out of 10 new replicas have been updated...
Waiting for rollout to finish: 6 out of 10 new replicas have been updated...
Waiting for rollout to finish: 7 out of 10 new replicas have been updated...
Waiting for rollout to finish: 7 out of 10 new replicas have been updated...
Waiting for rollout to finish: 7 out of 10 new replicas have been updated...
Waiting for rollout to finish: 7 out of 10 new replicas have been updated...
Waiting for rollout to finish: 8 out of 10 new replicas have been updated...
Waiting for rollout to finish: 8 out of 10 new replicas have been updated...
Waiting for rollout to finish: 8 out of 10 new replicas have been updated...
Waiting for rollout to finish: 9 out of 10 new replicas have been updated...
Waiting for rollout to finish: 9 out of 10 new replicas have been updated...
Waiting for rollout to finish: 9 out of 10 new replicas have been updated...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 9 of 10 updated replicas are available...
deployment "nginx-deployment" successfully rolled out
```
For more information about the status of a Deployment [read more here](#deployment-status).
## Updating a Deployment
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed,
@@ -129,7 +161,7 @@ To see its rollout status, simply run:
```shell
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment nginx-deployment successfully rolled out
deployment "nginx-deployment" successfully rolled out
```
After the rollout succeeds, you may want to `get` the Deployment:
@@ -244,12 +276,12 @@ deployment "nginx-deployment" image updated
The rollout will be stuck.
```
```shell
$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
```
Press Ctrl-C to stop the above rollout status watch.
Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts, [read more here](#deployment-status).
You will also see that both the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2.
@@ -413,7 +445,7 @@ $ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=
deployment "nginx-deployment" autoscaled
```
RollingUpdate Deployments support running multitple versions of an application at the same time. When you
RollingUpdate Deployments support running multiple versions of an application at the same time. When you
or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress
or paused), then the Deployment controller will balance the additional replicas in the existing active
ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*.
@@ -549,7 +581,7 @@ updates you've requested have been completed.
You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code.
```
```shell
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
@@ -568,7 +600,7 @@ Your Deployment may get stuck trying to deploy its newest ReplicaSet without eve
* Limit ranges
* Application runtime misconfiguration
One way you can detect this condition is to specify specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the number of seconds the Deployment controller waits before indicating (via the Deployment status) that the Deployment progress has stalled.
One way you can detect this condition is to specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the number of seconds the Deployment controller waits before indicating (via the Deployment status) that the Deployment progress has stalled.
The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report lack of progress for a Deployment after 10 minutes:
@@ -594,7 +626,7 @@ You may experience transient errors with your Deployments, either due to a low t
of error that can be treated as transient. For example, let's suppose you have insufficient quota. If you describe the Deployment
you will notice the following section:
```
```shell
$ kubectl describe deployment nginx-deployment
<...>
Conditions:
@@ -667,7 +699,7 @@ required new replicas are available (see the Reason of the condition for the par
You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` returns a non-zero exit code if the Deployment has exceeded the progression deadline.
```
```shell
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
docs/user-guide/federation/configmap.md
+2 -2
View File
@@ -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
docs/user-guide/federation/daemonsets.md
+2 -2
View File
@@ -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
docs/user-guide/federation/deployment.md
+2 -2
View File
@@ -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
docs/user-guide/federation/events.md
+2 -2
View File
@@ -24,10 +24,10 @@ general.
## Overview
Events in federation control plane (refered to as "federation events" in
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.
docs/user-guide/federation/federated-ingress.md
+1 -1
View File
@@ -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:
docs/user-guide/federation/federated-services.md
+3 -3
View File
@@ -232,7 +232,7 @@ due to caching by intermediate DNS servers.
The above set of DNS records is automatically kept in sync with the
current state of health of all service shards globally by the
Federated Service system. DNS resolver libraries (which are invoked by
all clients) automatically traverse the hiearchy of 'CNAME' and 'A'
all clients) automatically traverse the hierarchy of 'CNAME' and 'A'
records to return the correct set of healthy IP addresses. Clients can
then select any one of the returned addresses to initiate a network
connection (and fail over automatically to one of the other equivalent
@@ -295,7 +295,7 @@ availability zones and regions other than the ones local to a Pod by
specifying the appropriate DNS names explicitly, and not relying on
automatic DNS expansion. For example,
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
resolve to all of the currently healthy service shards in europe, even
resolve to all of the currently healthy service shards in Europe, even
if the Pod issuing the lookup is located in the U.S., and irrespective
of whether or not there are healthy shards of the service in the U.S.
This is useful for remote monitoring and other similar applications.
@@ -316,7 +316,7 @@ us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.ex
nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com.
```
That way your clients can always use the short form on the left, and
always be automatcally routed to the closest healthy shard on their
always be automatically routed to the closest healthy shard on their
home continent. All of the required failover is handled for you
automatically by Kubernetes Cluster Federation. Future releases will
improve upon this even further.
docs/user-guide/federation/index.md
+1 -1
View File
@@ -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.
docs/user-guide/federation/namespaces.md
+4 -4
View File
@@ -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:
docs/user-guide/federation/replicasets.md
+2 -2
View File
@@ -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
docs/user-guide/federation/secrets.md
+2 -2
View File
@@ -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
docs/user-guide/images.md
+1 -1
View File
@@ -296,7 +296,7 @@ will be merged. This approach will work on Google Container Engine (GKE).
There are a number of solutions for configuring private registries. Here are some
common use cases and suggested solutions.
1. Cluster running only non-proprietary (e.g open-source) images. No need to hide images.
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
- Use public images on the Docker hub.
- no configuration required
- on GCE/GKE, a local mirror is automatically used for improved speed and availability
docs/user-guide/ingress.md
+4 -4
View File
@@ -73,7 +73,7 @@ __Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion
__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
__Lines 8-9__: Each http rule contains the following information: A host (eg: foo.bar.com, defaults to * in this example), a list of paths (eg: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
__Lines 8-9__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
__Lines 10-12__: A backend is a service:port combination as described in the [services doc](/docs/user-guide/services). Ingress traffic is typically sent directly to the endpoints matching a backend.
@@ -185,7 +185,7 @@ __Default Backends__: An Ingress with no rules, like the one shown in the previo
### TLS
You can secure an Ingress by specifying a [secret](/docs/user-guide/secrets) that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS, eg:
You can secure an Ingress by specifying a [secret](/docs/user-guide/secrets) that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS, e.g.:
```yaml
apiVersion: v1
@@ -218,7 +218,7 @@ Note that there is a gap between TLS features supported by various Ingress contr
### Loadbalancing
An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (eg: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource.
An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource.
It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/production-pods.md#liveness-and-readiness-probes-aka-health-checks) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/README.md), [GCE](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md#health-checks)).
@@ -277,7 +277,7 @@ Techniques for spreading traffic across failure domains differs between cloud pr
## Future Work
* Various modes of HTTPS/TLS support (eg: SNI, re-encryption)
* Various modes of HTTPS/TLS support (e.g.: SNI, re-encryption)
* Requesting an IP or Hostname via claims
* Combining L4 and L7 Ingress
* More Ingress controllers

Some files were not shown because too many files have changed in this diff Show More