Merge branch 'master' into patch-1
This commit is contained in:
xilabao
@@ -86,7 +86,7 @@ For version 1.2, clusters created by `kube-up.sh` are configured so that no auth
|
||||
required for any request.
|
||||
|
||||
As of version 1.3, clusters created by `kube-up.sh` are configured so that the ABAC authorization
|
||||
modules is enabled. However, its input file is initially set to allow all users to do all
|
||||
modules are enabled. However, its input file is initially set to allow all users to do all
|
||||
operations. The cluster administrator needs to edit that file, or configure a different authorizer
|
||||
to restrict what users can do.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
|
||||
* [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/ku
|
||||
|
||||
When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`.
|
||||
|
||||
Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
|
||||
Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`).
|
||||
|
||||
An example request body:
|
||||
|
||||
@@ -151,7 +151,7 @@ An example request body:
|
||||
}
|
||||
```
|
||||
|
||||
The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s “spec” field is ignored and may be omitted. A permissive response would return:
|
||||
The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return:
|
||||
|
||||
```
|
||||
{
|
||||
|
||||
@@ -384,7 +384,7 @@ Specifying the default profile to apply to containers when none is provided:
|
||||
- **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName`
|
||||
- **value**: a profile reference, described above
|
||||
|
||||
Specifying the list of profiles Pod containers are allowed to specify:
|
||||
Specifying the list of profiles Pod containers is allowed to specify:
|
||||
|
||||
- **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
|
||||
- **value**: a comma-separated list of profile references (described above)
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -180,7 +180,7 @@ For the purposes of these flags, _legacy_ APIs are those APIs which have been ex
|
||||
|
||||
The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
|
||||
When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable
|
||||
by the kubernetes API server.
|
||||
by the Kubernetes API server.
|
||||
|
||||
`KUBE_API_VERSIONS` environment variable for the `kube-apiserver` binary which controls the API versions that are supported in the cluster. The first version in the list is used as the cluster's storage version. Hence, to set a specific version as the storage version, bring it to the front of list of versions in the value of `KUBE_API_VERSIONS`. You need to restart the `kube-apiserver` binary
|
||||
for changes to this variable to take effect.
|
||||
|
||||
@@ -89,7 +89,7 @@ Mitigations:
|
||||
- Mitigates: Apiserver VM shutdown or apiserver crashing
|
||||
- Mitigates: Supporting services VM shutdown or crashes
|
||||
|
||||
- Action use IaaS providers reliable storage (e.g GCE PD or AWS EBS volume) for VMs with apiserver+etcd
|
||||
- Action use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd
|
||||
- Mitigates: Apiserver backing storage lost
|
||||
|
||||
- Action: Use (experimental) [high-availability](/docs/admin/high-availability) configuration
|
||||
|
||||
@@ -129,7 +129,7 @@ Support for updating DaemonSets and controlled updating of nodes is planned.
|
||||
|
||||
### 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:
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
title: Pod Disruption Budget
|
||||
---
|
||||
This guide is for anyone wishing to specify safety constraints on pods or anyone
|
||||
wishing to write software (typically automation software) that respects those
|
||||
|
||||
@@ -100,6 +100,7 @@ metadata:
|
||||
spec:
|
||||
selector:
|
||||
name: busybox
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: foo # Actually, no port is needed.
|
||||
port: 1234
|
||||
|
||||
@@ -110,7 +110,7 @@ $ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh build_image
|
||||
$ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh push
|
||||
```
|
||||
|
||||
Note: This is going to overwite the values you might have set for
|
||||
Note: This is going to overwrite the values you might have set for
|
||||
`apiserverRegistry`, `apiserverVersion`, `controllerManagerRegistry` and
|
||||
`controllerManagerVersion` in your `${FEDERATION_OUTPUT_ROOT}/values.yaml`
|
||||
file. Hence, it is not recommend to customize these values in
|
||||
@@ -218,7 +218,7 @@ Once you've registered your cluster with the federation, you'll need to update K
|
||||
|
||||
### Kubernetes 1.5+: Passing federations flag via config map to kube-dns
|
||||
|
||||
For kubernetes clusters of version 1.5+, you can pass the
|
||||
For Kubernetes clusters of version 1.5+, you can pass the
|
||||
`--federations` flag to kube-dns via the kube-dns config map.
|
||||
The flag uses the following format:
|
||||
|
||||
@@ -352,7 +352,7 @@ $ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google-clouddns FEDERATION_NAM
|
||||
set appropriately if it is missing and `KUBERNETES_PROVIDER` is one of `gce`, `gke` and `aws`.
|
||||
This is used to resolve DNS requests for federation services. The service
|
||||
controller keeps DNS records with the provider updated as services/pods are
|
||||
updated in underlying kubernetes clusters.
|
||||
updated in underlying Kubernetes clusters.
|
||||
|
||||
`FEDERATION_NAME` is a name you can choose for your federation. This is the name that will appear in DNS routes.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ External garbage collection tools are not recommended as these tools can potenti
|
||||
|
||||
### Image Collection
|
||||
|
||||
kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
Kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
of cadvisor.
|
||||
|
||||
The policy for garbage collecting images takes two factors into consideration:
|
||||
|
||||
@@ -24,7 +24,7 @@ If true, reads will be directed to leader etcd replica.
|
||||
Setting this value to true is optional: reads will be more reliable but will also be slower.
|
||||
|
||||
Optionally, you can specify a GCE zone where the first master replica is to be created.
|
||||
Set the the following flag:
|
||||
Set the following flag:
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run.
|
||||
|
||||
|
||||
+3
-3
@@ -13,7 +13,7 @@ It assumes some familiarity with concepts in the [User Guide](/docs/user-guide/)
|
||||
|
||||
## Planning a cluster
|
||||
|
||||
There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this
|
||||
There are many different examples of how to setup a Kubernetes cluster. Many of them are listed in this
|
||||
[matrix](/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*.
|
||||
|
||||
Before choosing a particular guide, here are some things to consider:
|
||||
@@ -25,12 +25,12 @@ Before choosing a particular guide, here are some things to consider:
|
||||
- Will your cluster be on-premises, or in the cloud (IaaS)? Kubernetes does not directly support hybrid clusters. We
|
||||
recommend setting up multiple clusters rather than spanning distant locations.
|
||||
- Will you be running Kubernetes on "bare metal" or virtual machines? Kubernetes supports both, via different distros.
|
||||
- Do you just want to run a cluster, or do you expect to do active development of kubernetes project code? If the
|
||||
- Do you just want to run a cluster, or do you expect to do active development of Kubernetes project code? If the
|
||||
latter, it is better to pick a distro actively used by other developers. Some distros only use binary releases, but
|
||||
offer is a greater variety of choices.
|
||||
- Not all distros are maintained as actively. Prefer ones which are listed as tested on a more recent version of
|
||||
Kubernetes.
|
||||
- If you are configuring kubernetes on-premises, you will need to consider what [networking
|
||||
- If you are configuring Kubernetes on-premises, you will need to consider what [networking
|
||||
model](/docs/admin/networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](/docs/admin/multi-cluster).
|
||||
- You may want to familiarize yourself with the various
|
||||
|
||||
@@ -62,9 +62,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
|
||||
--horizontal-pod-autoscaler-sync-period duration The period for syncing the number of pods in horizontal pod autoscaler. (default 30s)
|
||||
--insecure-experimental-approve-all-kubelet-csrs-for-group string The group for which the controller-manager will auto approve all CSRs for kubelet client certificates.
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 30)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 30)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 20)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 20)
|
||||
--kubeconfig string Path to kubeconfig file with authorization and master location information.
|
||||
--large-cluster-size-threshold int32 Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller. (default 50)
|
||||
--leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true)
|
||||
|
||||
@@ -48,9 +48,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--iptables-masquerade-bit int32 If using the pure iptables proxy, the bit of the fwmark space to mark packets requiring SNAT with. Must be within the range [0, 31]. (default 14)
|
||||
--iptables-min-sync-period duration The minimum interval of how often the iptables rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m').
|
||||
--iptables-sync-period duration The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m'). Must be greater than 0. (default 30s)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 5)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 5)
|
||||
--kubeconfig string Path to kubeconfig file with authorization information (the master location is set by the master flag).
|
||||
--masquerade-all If using the pure iptables proxy, SNAT everything
|
||||
--master string The address of the Kubernetes API server (overrides any value in kubeconfig)
|
||||
|
||||
@@ -38,9 +38,9 @@ ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false)
|
||||
StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication.
|
||||
--hard-pod-affinity-symmetric-weight int RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. (default 1)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 100)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 100)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 50)
|
||||
--kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 50)
|
||||
--kubeconfig string Path to kubeconfig file with authorization and master location information.
|
||||
--leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true)
|
||||
--leader-elect-lease-duration duration The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled. (default 15s)
|
||||
|
||||
@@ -107,9 +107,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--image-service-endpoint string [Experimental] The unix socket endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. The endpoint is used only when CRI integration is enabled (--experimental-cri)
|
||||
--iptables-drop-bit int32 The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15)
|
||||
--iptables-masquerade-bit int32 The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14)
|
||||
--kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10)
|
||||
--kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10)
|
||||
--kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf")
|
||||
--kube-api-qps int32 QPS to use while talking with kubernetes apiserver (default 5)
|
||||
--kube-api-qps int32 QPS to use while talking with Kubernetes apiserver (default 5)
|
||||
--kube-reserved mapStringString A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs that describe resources reserved for kubernetes system components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none]
|
||||
--kubeconfig string Path to a kubeconfig file, specifying how to connect to the API server. --api-servers will be used for the location unless --require-kubeconfig is set. (default "/var/lib/kubelet/kubeconfig")
|
||||
--kubelet-cgroups string Optional absolute name of cgroups to create and run the Kubelet in.
|
||||
@@ -118,7 +118,7 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--make-iptables-util-chains If true, kubelet will ensure iptables utility rules are present on host. (default true)
|
||||
--manifest-url string URL for accessing the container manifest
|
||||
--manifest-url-header string HTTP header to use when accessing the manifest URL, with the key separated from the value with a ':', as in 'key:value'
|
||||
--master-service-namespace string The namespace from which the kubernetes master services should be injected into pods (default "default")
|
||||
--master-service-namespace string The namespace from which the Kubernetes master services should be injected into pods (default "default")
|
||||
--max-open-files int Number of files that can be opened by Kubelet process. [default=1000000] (default 1000000)
|
||||
--max-pods int32 Number of Pods that can run on this Kubelet. (default 110)
|
||||
--minimum-image-ttl-duration duration Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. Default: '2m' (default 2m0s)
|
||||
|
||||
@@ -8,7 +8,7 @@ You may want to set up multiple Kubernetes clusters, both to
|
||||
have clusters in different regions to be nearer to your users, and to tolerate failures and/or invasive maintenance.
|
||||
This document describes some of the issues to consider when making a decision about doing so.
|
||||
|
||||
If you decide to have multiple clusters, kubernetes provides a way to [federate them](/docs/admin/federation/)
|
||||
If you decide to have multiple clusters, Kubernetes provides a way to [federate them](/docs/admin/federation/)
|
||||
|
||||
## Scope of a single cluster
|
||||
|
||||
@@ -52,7 +52,7 @@ Second, decide how many clusters should be able to be unavailable at the same ti
|
||||
the number that can be unavailable `U`. If you are not sure, then 1 is a fine choice.
|
||||
|
||||
If it is allowable for load-balancing to direct traffic to any region in the event of a cluster failure, then
|
||||
you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g you want to ensure low latency for all
|
||||
you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g. you want to ensure low latency for all
|
||||
users in the event of a cluster failure), then you need to have `R * (U + 1)` clusters
|
||||
(`U + 1` in each of `R` regions). In any case, try to put each cluster in a different zone.
|
||||
|
||||
|
||||
@@ -151,7 +151,7 @@ Let's create some content.
|
||||
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
```
|
||||
We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
|
||||
Note that `kubectl run` creates deployments only on kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -32,7 +32,7 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used,
|
||||
|
||||
### Exec
|
||||
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e. if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
|
||||
### CNI
|
||||
|
||||
@@ -50,13 +50,10 @@ Kubenet is a very basic, simple network plugin, on Linux only. It does not, of
|
||||
|
||||
Kubenet creates a Linux bridge named `cbr0` and creates a veth pair for each pod with the host end of each pair connected to `cbr0`. The pod end of the pair is assigned an IP address allocated from a range assigned to the node either through configuration or by the controller-manager. `cbr0` is assigned an MTU matching the smallest MTU of an enabled normal interface on the host.
|
||||
|
||||
The kubenet plugin is mutually exclusive with the --configure-cbr0 option.
|
||||
|
||||
The plugin requires a few things:
|
||||
|
||||
* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect.
|
||||
* Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin
|
||||
* Kubelet must also be run with the `--reconcile-cidr` argument to ensure the IP subnet assigned to the node by configuration or the controller-manager is propagated to the plugin
|
||||
* Kubelet should also be run with the `--non-masquerade-cidr=<clusterCidr>` argumment to ensure traffic to IPs outside this range will use IP masquerade.
|
||||
* The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=<cidr>` controller-manager command-line options.
|
||||
|
||||
|
||||
@@ -173,7 +173,7 @@ Lars Kellogg-Stedman.
|
||||
|
||||
[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage’s policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform’s real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ either `kubectl` or addon pod.
|
||||
|
||||
### Kubectl
|
||||
|
||||
This is the recommanded way to start node problem detector outside of GCE. It
|
||||
This is the recommended way to start node problem detector outside of GCE. It
|
||||
provides more flexible management, such as overwriting the default
|
||||
configuration to fit it into your environment or detect
|
||||
customized node problems.
|
||||
@@ -238,7 +238,7 @@ implement a new translator for a new log format.
|
||||
|
||||
## Caveats
|
||||
|
||||
It is recommanded to run the node problem detector in your cluster to monitor
|
||||
It is recommended to run the node problem detector in your cluster to monitor
|
||||
the node health. However, you should be aware that this will introduce extra
|
||||
resource overhead on each node. Usually this is fine, because:
|
||||
|
||||
|
||||
+1
-1
@@ -244,6 +244,6 @@ on each kubelet where you want to reserve resources.
|
||||
|
||||
## API Object
|
||||
|
||||
Node is a top-level resource in the kubernetes REST API. More details about the
|
||||
Node is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at: [Node API
|
||||
object](/docs/api-reference/v1/definitions/#_v1_node).
|
||||
|
||||
@@ -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.
|
||||
@@ -57,4 +57,3 @@ and have the following annotations specified:
|
||||
* `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.
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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`)
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Running Kubernetes on CenturyLink Cloud
|
||||
* TOC
|
||||
{: toc}
|
||||
|
||||
These scripts handle the creation, deletion and expansion of kubernetes clusters on CenturyLink Cloud.
|
||||
These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
|
||||
|
||||
You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
|
||||
|
||||
@@ -13,7 +13,7 @@ You can accomplish all these tasks with a single command. We have made the Ansib
|
||||
|
||||
If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
|
||||
- Submit a github issue
|
||||
- Send an email to kubernetes AT ctl DOT io
|
||||
- Send an email to Kubernetes AT ctl DOT io
|
||||
- Visit http://info.ctl.io/kubernetes
|
||||
|
||||
## Clusters of VMs or Physical Servers, your choice.
|
||||
@@ -212,13 +212,13 @@ 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```.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Configuring Kubernetes on Fedora via Ansible offers a simple way to quickly crea
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Host able to run ansible and able to clone the following repo: [kubernetes](https://github.com/kubernetes/kubernetes.git)
|
||||
1. Host able to run ansible and able to clone the following repo: [Kubernetes](https://github.com/kubernetes/kubernetes.git)
|
||||
2. A Fedora 21+ host to act as cluster master
|
||||
3. As many Fedora 21+ hosts as you would like, that act as cluster nodes
|
||||
|
||||
@@ -101,9 +101,9 @@ Although the default value of variables in `~/contrib/ansible/group_vars/all.yml
|
||||
edit: ~/contrib/ansible/group_vars/all.yml
|
||||
```
|
||||
|
||||
**Configure access to kubernetes packages**
|
||||
**Configure access to Kubernetes packages**
|
||||
|
||||
Modify `source_type` as below to access kubernetes packages through the package manager.
|
||||
Modify `source_type` as below to access Kubernetes packages through the package manager.
|
||||
|
||||
```yaml
|
||||
source_type: packageManager
|
||||
@@ -156,7 +156,7 @@ cd ~/contrib/ansible/
|
||||
|
||||
That's all there is to it. It's really that easy. At this point you should have a functioning Kubernetes cluster.
|
||||
|
||||
**Show kubernetes nodes**
|
||||
**Show Kubernetes nodes**
|
||||
|
||||
Run the following on the kube-master:
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ fed-node = 192.168.121.65
|
||||
|
||||
**Prepare the hosts:**
|
||||
|
||||
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with kubernetes-0.18 and beyond.
|
||||
* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond.
|
||||
* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the changing the `enable=0` to `enable=1` for extras.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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`.
|
||||
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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`
|
||||
|
||||
|
||||
@@ -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.`
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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`.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ assignees:
|
||||
|
||||
---
|
||||
|
||||
This document describes how to deploy kubernetes on ubuntu nodes, 1 master and 3 nodes involved
|
||||
This document describes how to deploy Kubernetes on ubuntu nodes, 1 master and 3 nodes involved
|
||||
in the given examples. You can scale to **any number of nodes** by changing some settings with ease.
|
||||
The original idea was heavily inspired by @jainvipin 's ubuntu single node
|
||||
work, which has been merge into this document.
|
||||
@@ -36,7 +36,7 @@ Ubuntu 15 which uses systemd instead of upstart.
|
||||
|
||||
### Set up working directory
|
||||
|
||||
Clone the kubernetes github repo locally
|
||||
Clone the Kubernetes github repo locally
|
||||
|
||||
```shell
|
||||
$ git clone --depth 1 https://github.com/kubernetes/kubernetes.git
|
||||
@@ -101,7 +101,7 @@ acts as both master and node, "a" stands for master, "i" stands for node.
|
||||
|
||||
The `NUM_NODES` variable defines the total number of nodes.
|
||||
|
||||
The `SERVICE_CLUSTER_IP_RANGE` variable defines the kubernetes service IP range. Please make sure
|
||||
The `SERVICE_CLUSTER_IP_RANGE` variable defines the Kubernetes service IP range. Please make sure
|
||||
that you do have a valid private ip range defined here, because some IaaS provider may reserve private ips.
|
||||
You can use below three private network range according to rfc1918. Besides you'd better not choose the one
|
||||
that conflicts with your own private network range.
|
||||
@@ -138,7 +138,7 @@ bring up the whole cluster.
|
||||
$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
|
||||
```
|
||||
|
||||
The scripts automatically copy binaries and config files to all the machines via `scp` and start kubernetes
|
||||
The scripts automatically copy binaries and config files to all the machines via `scp` and start Kubernetes
|
||||
service on them. The only thing you need to do is to type the sudo password when promoted.
|
||||
|
||||
```shell
|
||||
@@ -211,7 +211,7 @@ After some time, you can use `$ kubectl get pods --namespace=kube-system` to see
|
||||
|
||||
We are working on these features which we'd like to let everybody know:
|
||||
|
||||
1. Run kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube),
|
||||
1. Run Kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube),
|
||||
to eliminate OS-distro differences.
|
||||
2. Tearing Down scripts: clear and re-create the whole stack by one click.
|
||||
|
||||
@@ -239,7 +239,7 @@ $ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
|
||||
|
||||
## Upgrading a Cluster
|
||||
|
||||
If you already have a kubernetes cluster, and want to upgrade to a new version,
|
||||
If you already have a Kubernetes cluster, and want to upgrade to a new version,
|
||||
you can use following command in `cluster/` directory to update the whole cluster
|
||||
or a specified node to a new version.
|
||||
|
||||
@@ -285,7 +285,7 @@ The script will not delete any resources of your cluster, it just replaces the b
|
||||
|
||||
### Test it out
|
||||
|
||||
You can use the `kubectl` command to check if the newly upgraded kubernetes cluster is working correctly.
|
||||
You can use the `kubectl` command to check if the newly upgraded Kubernetes cluster is working correctly.
|
||||
|
||||
To make sure the version of the upgraded cluster is what you expect, you will find these commands helpful.
|
||||
|
||||
|
||||
@@ -5,19 +5,96 @@ 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 +102,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 +112,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 +168,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 +177,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 +203,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 +215,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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
+11
-11
@@ -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.
|
||||
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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>
|
||||
```
|
||||
|
||||
@@ -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>
|
||||
|
||||
+12
-10
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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">
|
||||
|
||||
@@ -28,7 +28,7 @@ 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>
|
||||
@@ -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>
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
FROM node:6.9.2
|
||||
EXPOSE 8080
|
||||
COPY server.js .
|
||||
CMD node server.js
|
||||
@@ -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 %}
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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);
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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" %}
|
||||
|
||||
|
||||
@@ -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!
|
||||
|
||||
@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myconfigmap.yaml
|
||||
```
|
||||
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated ConfigMap is created, the federation control plane will create
|
||||
a matching ConfigMap in all underlying kubernetes clusters.
|
||||
a matching ConfigMap in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
||||
@@ -44,11 +44,11 @@ kubectl --context=federation-cluster create -f mydaemonset.yaml
|
||||
```
|
||||
|
||||
The `--context=federation-cluster` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated Daemonset is created, the federation control plane will create
|
||||
a matching DaemonSet in all underlying kubernetes clusters.
|
||||
a matching DaemonSet in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
||||
@@ -47,11 +47,11 @@ kubectl --context=federation-cluster create -f mydeployment.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a Federated Deployment is created, the federation control plane will create
|
||||
a Deployment in all underlying kubernetes clusters.
|
||||
a Deployment in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Federation User Guide
|
||||
---
|
||||
|
||||
This guide explains how we can manage multiple kubernetes clusters using
|
||||
This guide explains how we can manage multiple Kubernetes clusters using
|
||||
federation.
|
||||
[Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md)
|
||||
details the use cases motivating cluster federation.
|
||||
|
||||
@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myns.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated namespace is created, the federation control plane will create
|
||||
a matching namespace in all underlying kubernetes clusters.
|
||||
a matching namespace in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
@@ -64,7 +64,7 @@ the Federated Namespace that you created above.
|
||||
|
||||
You can update a federated namespace as you would update a Kubernetes
|
||||
namespace, just send the request to federation apiserver instead of sending it
|
||||
to a specific kubernetes cluster.
|
||||
to a specific Kubernetes cluster.
|
||||
Federation control plan will ensure that whenever the federated namespace is
|
||||
updated, it updates the corresponding namespaces in all underlying clusters to
|
||||
match it.
|
||||
@@ -73,7 +73,7 @@ match it.
|
||||
|
||||
You can delete a federated namespace as you would delete a Kubernetes
|
||||
namespace, just send the request to federation apiserver instead of sending it
|
||||
to a specific kubernetes cluster.
|
||||
to a specific Kubernetes cluster.
|
||||
|
||||
For example, you can do that using kubectl by running:
|
||||
|
||||
|
||||
@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myrs.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated replica set is created, the federation control plane will create
|
||||
a replica set in all underlying kubernetes clusters.
|
||||
a replica set in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
||||
@@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f mysecret.yaml
|
||||
```
|
||||
|
||||
The '--context=federation-cluster' flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a kubernetes
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated secret is created, the federation control plane will create
|
||||
a matching secret in all underlying kubernetes clusters.
|
||||
a matching secret in all underlying Kubernetes clusters.
|
||||
You can verify this by checking each of the underlying clusters, for example:
|
||||
|
||||
``` shell
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -24,7 +24,7 @@ A Job can also be used to run multiple pods in parallel.
|
||||
### extensions/v1beta1.Job is deprecated
|
||||
|
||||
Starting from version 1.5 `extensions/v1beta1.Job` is being deprecated, with a plan to be removed in
|
||||
version 1.6 of kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
|
||||
version 1.6 of Kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)).
|
||||
Please use `batch/v1.Job` instead.
|
||||
|
||||
## Running an example Job
|
||||
|
||||
@@ -109,7 +109,7 @@ Processing item cherry
|
||||
|
||||
In the first example, each instance of the template had one parameter, and that parameter was also
|
||||
used as a label. However label keys are limited in [what characters they can
|
||||
contain](docs/user-guide/labels/#syntax-and-character-set).
|
||||
contain](/docs/user-guide/labels/#syntax-and-character-set).
|
||||
|
||||
This slightly more complex example uses a the jinja2 template language to generate our objects.
|
||||
We will use a one-line python script to convert the template to a file.
|
||||
@@ -128,7 +128,7 @@ First, copy and paste the following template of a Job object, into a file called
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: jobexample-{{ {{ name }} }}
|
||||
name: jobexample-{{ name }}
|
||||
labels:
|
||||
jobgroup: jobexample
|
||||
spec:
|
||||
@@ -188,7 +188,7 @@ If you have a large number of job objects, you may find that:
|
||||
concurrent requests to a shared resource, such as a database,
|
||||
used by all the pods in the job.
|
||||
- very large numbers of jobs created at once overload the
|
||||
kubernetes apiserver, controller, or scheduler.
|
||||
Kubernetes apiserver, controller, or scheduler.
|
||||
|
||||
In this case, you can consider one of the
|
||||
other [job patterns](/docs/user-guide/jobs/#job-patterns).
|
||||
|
||||
@@ -95,7 +95,7 @@ class RedisWQ(object):
|
||||
# Record that we (this session id) are working on a key. Expire that
|
||||
# note after the lease timeout.
|
||||
# Note: if we crash at this line of the program, then GC will see no lease
|
||||
# for this item an later return it to the main queue.
|
||||
# for this item a later return it to the main queue.
|
||||
itemkey = self._itemkey(item)
|
||||
self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session)
|
||||
return item
|
||||
|
||||
+307
-307
@@ -5,310 +5,310 @@ assignees:
|
||||
title: Authenticating Across Clusters with kubeconfig
|
||||
---
|
||||
|
||||
Authentication in kubernetes can differ for different individuals.
|
||||
|
||||
- A running kubelet might have one way of authenticating (i.e. certificates).
|
||||
- Users might have a different way of authenticating (i.e. tokens).
|
||||
- Administrators might have a list of certificates which they provide individual users.
|
||||
- There may be multiple clusters, and we may want to define them all in one place - giving users the ability to use their own certificates and reusing the same global configuration.
|
||||
|
||||
So in order to easily switch between multiple clusters, for multiple users, a kubeconfig file was defined.
|
||||
|
||||
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
||||
|
||||
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below).
|
||||
|
||||
## Related discussion
|
||||
|
||||
http://issue.k8s.io/1755
|
||||
|
||||
## Components of a kubeconfig file
|
||||
|
||||
### Example kubeconfig file
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
api-version: v1
|
||||
server: http://cow.org:8080
|
||||
name: cow-cluster
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
- context:
|
||||
cluster: pig-cluster
|
||||
namespace: saw-ns
|
||||
user: black-user
|
||||
name: queen-anne-context
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
### Breakdown/explanation of components
|
||||
|
||||
#### cluster
|
||||
|
||||
```yaml
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
```
|
||||
|
||||
A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
|
||||
qualified url for the kubernetes apiserver, as well as the cluster's certificate
|
||||
authority or `insecure-skip-tls-verify: true`, if the cluster's serving
|
||||
certificate is not signed by a system trusted certificate authority.
|
||||
A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
|
||||
within this kubeconfig file. You can add or modify `cluster` entries using
|
||||
[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/).
|
||||
|
||||
#### user
|
||||
|
||||
```yaml
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
A `user` defines client credentials for authenticating to a kubernetes cluster. A
|
||||
`user` has a name (nickname) which acts as its key within the list of user entries
|
||||
after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
|
||||
`client-key`, `token`, and `username/password`. `username/password` and `token`
|
||||
are mutually exclusive, but client certs and keys can be combined with them.
|
||||
You can add or modify `user` entries using
|
||||
[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials).
|
||||
|
||||
#### context
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
```
|
||||
|
||||
A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple
|
||||
which is used to send requests to the specified cluster using the provided authentication info and
|
||||
namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`,
|
||||
`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding
|
||||
entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file)
|
||||
will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior.
|
||||
You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context).
|
||||
|
||||
#### current-context
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
```
|
||||
|
||||
`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl
|
||||
will use by default when loading config from this file. You can override any of the values in kubectl
|
||||
from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
|
||||
You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context).
|
||||
|
||||
#### miscellaneous
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
```
|
||||
|
||||
`apiVersion` and `kind` identify the version and schema for the client parser and should not
|
||||
be edited manually.
|
||||
|
||||
`preferences` specify optional (and currently unused) kubectl preferences.
|
||||
|
||||
## Viewing kubeconfig files
|
||||
|
||||
`kubectl config view` will display the current kubeconfig settings. By default
|
||||
it will show you all loaded kubeconfig settings; you can filter the view to just
|
||||
the settings relevant to the `current-context` by passing `--minify`. See
|
||||
[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options.
|
||||
|
||||
## Building your own kubeconfig file
|
||||
|
||||
NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you.
|
||||
|
||||
In any case, you can easily use this file as a template to create your own kubeconfig files.
|
||||
|
||||
So, lets do a quick walk through the basics of the above file so you can easily modify it as needed...
|
||||
|
||||
The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this:
|
||||
|
||||
```conf
|
||||
blue-user,blue-user,1
|
||||
mister-red,mister-red,2
|
||||
```
|
||||
|
||||
Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes).
|
||||
|
||||
- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials.
|
||||
- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context.
|
||||
|
||||
In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the
|
||||
|
||||
## Loading and merging rules
|
||||
|
||||
The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order:
|
||||
|
||||
1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules:
|
||||
|
||||
|
||||
If the `CommandLineLocation` (the value of the `kubeconfig` command line option) is set, use this file only. No merging. Only one instance of this flag is allowed.
|
||||
|
||||
|
||||
Else, if `EnvVarLocation` (the value of `$KUBECONFIG`) is available, use it as a list of files that should be merged.
|
||||
Merge files together based on the following rules.
|
||||
Empty filenames are ignored. Files with non-deserializable content produced errors.
|
||||
The first file to set a particular value or map key wins and the value or map key is never changed.
|
||||
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded.
|
||||
|
||||
|
||||
Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging.
|
||||
1. Determine the context to use based on the first hit in this chain
|
||||
1. command line argument - the value of the `context` command line option
|
||||
1. `current-context` from the merged kubeconfig file
|
||||
1. Empty is allowed at this stage
|
||||
1. Determine the cluster info and user to use. At this point, we may or may not have a context. They are built based on the first hit in this chain. (run it twice, once for user, once for cluster)
|
||||
1. command line argument - `user` for user name and `cluster` for cluster name
|
||||
1. If context is present, then use the context's value
|
||||
1. Empty is allowed
|
||||
1. Determine the actual cluster info to use. At this point, we may or may not have a cluster info. Build each piece of the cluster info based on the chain (first hit wins):
|
||||
1. command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify`
|
||||
1. If cluster info is present and a value for the attribute is present, use it.
|
||||
1. If you don't have a server location, error.
|
||||
1. Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user.
|
||||
1. Load precedence is 1) command line flag, 2) user fields from kubeconfig
|
||||
1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`.
|
||||
1. If there are two conflicting techniques, fail.
|
||||
1. For any information still missing, use default values and potentially prompt for authentication information
|
||||
1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line
|
||||
they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely.
|
||||
|
||||
Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself.
|
||||
|
||||
|
||||
## Manipulation of kubeconfig via `kubectl config <subcommand>`
|
||||
|
||||
In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help.
|
||||
See [kubectl/kubectl_config.md](/docs/user-guide/kubectl/kubectl_config) for help.
|
||||
|
||||
### Example
|
||||
|
||||
```shell
|
||||
$ kubectl config set-credentials myself --username=admin --password=secret
|
||||
$ kubectl config set-cluster local-server --server=http://localhost:8080
|
||||
$ kubectl config set-context default-context --cluster=local-server --user=myself
|
||||
$ kubectl config use-context default-context
|
||||
$ kubectl config set contexts.default-context.namespace the-right-prefix
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
produces this output
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
server: http://localhost:8080
|
||||
name: local-server
|
||||
contexts:
|
||||
- context:
|
||||
cluster: local-server
|
||||
namespace: the-right-prefix
|
||||
user: myself
|
||||
name: default-context
|
||||
current-context: default-context
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: myself
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
and a kubeconfig file that looks like this
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
server: http://localhost:8080
|
||||
name: local-server
|
||||
contexts:
|
||||
- context:
|
||||
cluster: local-server
|
||||
namespace: the-right-prefix
|
||||
user: myself
|
||||
name: default-context
|
||||
current-context: default-context
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: myself
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
#### Commands for the example file
|
||||
|
||||
```shell
|
||||
$ kubectl config set preferences.colors true
|
||||
$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1
|
||||
$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile
|
||||
$ kubectl config set-cluster pig-cluster --server=https://pig.org:443 --insecure-skip-tls-verify=true
|
||||
$ kubectl config set-credentials blue-user --token=blue-token
|
||||
$ kubectl config set-credentials green-user --client-certificate=path/to/my/client/cert --client-key=path/to/my/client/key
|
||||
$ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=black-user --namespace=saw-ns
|
||||
$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns
|
||||
$ kubectl config use-context federal-context
|
||||
```
|
||||
|
||||
### Final notes for tying it all together
|
||||
|
||||
So, tying this all together, a quick start to creating your own kubeconfig file:
|
||||
|
||||
- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
|
||||
|
||||
- Replace the snippet above with information for your cluster's api-server endpoint.
|
||||
|
||||
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
||||
Authentication in kubernetes can differ for different individuals.
|
||||
|
||||
- A running kubelet might have one way of authenticating (i.e. certificates).
|
||||
- Users might have a different way of authenticating (i.e. tokens).
|
||||
- Administrators might have a list of certificates which they provide individual users.
|
||||
- There may be multiple clusters, and we may want to define them all in one place - giving users the ability to use their own certificates and reusing the same global configuration.
|
||||
|
||||
So in order to easily switch between multiple clusters, for multiple users, a kubeconfig file was defined.
|
||||
|
||||
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
|
||||
|
||||
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below).
|
||||
|
||||
## Related discussion
|
||||
|
||||
http://issue.k8s.io/1755
|
||||
|
||||
## Components of a kubeconfig file
|
||||
|
||||
### Example kubeconfig file
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
api-version: v1
|
||||
server: http://cow.org:8080
|
||||
name: cow-cluster
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
- context:
|
||||
cluster: pig-cluster
|
||||
namespace: saw-ns
|
||||
user: black-user
|
||||
name: queen-anne-context
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
### Breakdown/explanation of components
|
||||
|
||||
#### cluster
|
||||
|
||||
```yaml
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: path/to/my/cafile
|
||||
server: https://horse.org:4443
|
||||
name: horse-cluster
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://pig.org:443
|
||||
name: pig-cluster
|
||||
```
|
||||
|
||||
A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully
|
||||
qualified url for the kubernetes apiserver, as well as the cluster's certificate
|
||||
authority or `insecure-skip-tls-verify: true`, if the cluster's serving
|
||||
certificate is not signed by a system trusted certificate authority.
|
||||
A `cluster` has a name (nickname) which acts as a dictionary key for the cluster
|
||||
within this kubeconfig file. You can add or modify `cluster` entries using
|
||||
[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/).
|
||||
|
||||
#### user
|
||||
|
||||
```yaml
|
||||
users:
|
||||
- name: blue-user
|
||||
user:
|
||||
token: blue-token
|
||||
- name: green-user
|
||||
user:
|
||||
client-certificate: path/to/my/client/cert
|
||||
client-key: path/to/my/client/key
|
||||
```
|
||||
|
||||
A `user` defines client credentials for authenticating to a kubernetes cluster. A
|
||||
`user` has a name (nickname) which acts as its key within the list of user entries
|
||||
after kubeconfig is loaded/merged. Available credentials are `client-certificate`,
|
||||
`client-key`, `token`, and `username/password`. `username/password` and `token`
|
||||
are mutually exclusive, but client certs and keys can be combined with them.
|
||||
You can add or modify `user` entries using
|
||||
[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials).
|
||||
|
||||
#### context
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: horse-cluster
|
||||
namespace: chisel-ns
|
||||
user: green-user
|
||||
name: federal-context
|
||||
```
|
||||
|
||||
A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple
|
||||
which is used to send requests to the specified cluster using the provided authentication info and
|
||||
namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`,
|
||||
`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding
|
||||
entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file)
|
||||
will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior.
|
||||
You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context).
|
||||
|
||||
#### current-context
|
||||
|
||||
```yaml
|
||||
current-context: federal-context
|
||||
```
|
||||
|
||||
`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl
|
||||
will use by default when loading config from this file. You can override any of the values in kubectl
|
||||
from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
|
||||
You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context).
|
||||
|
||||
#### miscellaneous
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences:
|
||||
colors: true
|
||||
```
|
||||
|
||||
`apiVersion` and `kind` identify the version and schema for the client parser and should not
|
||||
be edited manually.
|
||||
|
||||
`preferences` specify optional (and currently unused) kubectl preferences.
|
||||
|
||||
## Viewing kubeconfig files
|
||||
|
||||
`kubectl config view` will display the current kubeconfig settings. By default
|
||||
it will show you all loaded kubeconfig settings; you can filter the view to just
|
||||
the settings relevant to the `current-context` by passing `--minify`. See
|
||||
[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options.
|
||||
|
||||
## Building your own kubeconfig file
|
||||
|
||||
NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you.
|
||||
|
||||
In any case, you can easily use this file as a template to create your own kubeconfig files.
|
||||
|
||||
So, lets do a quick walk through the basics of the above file so you can easily modify it as needed...
|
||||
|
||||
The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this:
|
||||
|
||||
```conf
|
||||
blue-user,blue-user,1
|
||||
mister-red,mister-red,2
|
||||
```
|
||||
|
||||
Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes).
|
||||
|
||||
- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials.
|
||||
- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context.
|
||||
|
||||
In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the
|
||||
|
||||
## Loading and merging rules
|
||||
|
||||
The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order:
|
||||
|
||||
1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules:
|
||||
|
||||
|
||||
If the `CommandLineLocation` (the value of the `kubeconfig` command line option) is set, use this file only. No merging. Only one instance of this flag is allowed.
|
||||
|
||||
|
||||
Else, if `EnvVarLocation` (the value of `$KUBECONFIG`) is available, use it as a list of files that should be merged.
|
||||
Merge files together based on the following rules.
|
||||
Empty filenames are ignored. Files with non-deserializable content produced errors.
|
||||
The first file to set a particular value or map key wins and the value or map key is never changed.
|
||||
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded.
|
||||
|
||||
|
||||
Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging.
|
||||
1. Determine the context to use based on the first hit in this chain
|
||||
1. command line argument - the value of the `context` command line option
|
||||
1. `current-context` from the merged kubeconfig file
|
||||
1. Empty is allowed at this stage
|
||||
1. Determine the cluster info and user to use. At this point, we may or may not have a context. They are built based on the first hit in this chain. (run it twice, once for user, once for cluster)
|
||||
1. command line argument - `user` for user name and `cluster` for cluster name
|
||||
1. If context is present, then use the context's value
|
||||
1. Empty is allowed
|
||||
1. Determine the actual cluster info to use. At this point, we may or may not have a cluster info. Build each piece of the cluster info based on the chain (first hit wins):
|
||||
1. command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify`
|
||||
1. If cluster info is present and a value for the attribute is present, use it.
|
||||
1. If you don't have a server location, error.
|
||||
1. Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user.
|
||||
1. Load precedence is 1) command line flag, 2) user fields from kubeconfig
|
||||
1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`.
|
||||
1. If there are two conflicting techniques, fail.
|
||||
1. For any information still missing, use default values and potentially prompt for authentication information
|
||||
1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line
|
||||
they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely.
|
||||
|
||||
Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself.
|
||||
|
||||
|
||||
## Manipulation of kubeconfig via `kubectl config <subcommand>`
|
||||
|
||||
In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help.
|
||||
See [kubectl/kubectl_config.md](/docs/user-guide/kubectl/kubectl_config) for help.
|
||||
|
||||
### Example
|
||||
|
||||
```shell
|
||||
$ kubectl config set-credentials myself --username=admin --password=secret
|
||||
$ kubectl config set-cluster local-server --server=http://localhost:8080
|
||||
$ kubectl config set-context default-context --cluster=local-server --user=myself
|
||||
$ kubectl config use-context default-context
|
||||
$ kubectl config set contexts.default-context.namespace the-right-prefix
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
produces this output
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
server: http://localhost:8080
|
||||
name: local-server
|
||||
contexts:
|
||||
- context:
|
||||
cluster: local-server
|
||||
namespace: the-right-prefix
|
||||
user: myself
|
||||
name: default-context
|
||||
current-context: default-context
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: myself
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
and a kubeconfig file that looks like this
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
server: http://localhost:8080
|
||||
name: local-server
|
||||
contexts:
|
||||
- context:
|
||||
cluster: local-server
|
||||
namespace: the-right-prefix
|
||||
user: myself
|
||||
name: default-context
|
||||
current-context: default-context
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: myself
|
||||
user:
|
||||
password: secret
|
||||
username: admin
|
||||
```
|
||||
|
||||
#### Commands for the example file
|
||||
|
||||
```shell
|
||||
$ kubectl config set preferences.colors true
|
||||
$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1
|
||||
$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile
|
||||
$ kubectl config set-cluster pig-cluster --server=https://pig.org:443 --insecure-skip-tls-verify=true
|
||||
$ kubectl config set-credentials blue-user --token=blue-token
|
||||
$ kubectl config set-credentials green-user --client-certificate=path/to/my/client/cert --client-key=path/to/my/client/key
|
||||
$ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=black-user --namespace=saw-ns
|
||||
$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns
|
||||
$ kubectl config use-context federal-context
|
||||
```
|
||||
|
||||
### Final notes for tying it all together
|
||||
|
||||
So, tying this all together, a quick start to creating your own kubeconfig file:
|
||||
|
||||
- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
|
||||
|
||||
- Replace the snippet above with information for your cluster's api-server endpoint.
|
||||
|
||||
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
|
||||
|
||||
@@ -101,6 +101,7 @@ Resource type | Abbreviated alias
|
||||
`nodes` |`no`
|
||||
`persistentvolumeclaims` |`pvc`
|
||||
`persistentvolumes` |`pv`
|
||||
`poddisruptionbudget` |`pdb`
|
||||
`pods` |`po`
|
||||
`podsecuritypolicies` |`psp`
|
||||
`podtemplates` |
|
||||
@@ -112,6 +113,7 @@ Resource type | Abbreviated alias
|
||||
`secrets` |
|
||||
`serviceaccounts` |`sa`
|
||||
`services` |`svc`
|
||||
`statefulsets` |
|
||||
`storageclasses` |
|
||||
`thirdpartyresources` |
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ Auto-scale a Deployment, ReplicaSet, or ReplicationController
|
||||
### Synopsis
|
||||
|
||||
|
||||
Creates an autoscaler that automatically chooses and sets the number of pods that run in a kubernetes cluster.
|
||||
Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster.
|
||||
|
||||
Looks up a Deployment, ReplicaSet, or ReplicationController by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ Dump lots of relevant info for debugging and diagnosis
|
||||
### Synopsis
|
||||
|
||||
|
||||
Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
|
||||
Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, Kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces.
|
||||
|
||||
The command also dumps the logs of all of the pods in the cluster, these logs are dumped into different directories based on namespace and pod name.
|
||||
|
||||
|
||||
@@ -11,13 +11,13 @@ Drain node in preparation for maintenance
|
||||
|
||||
Drain node in preparation for maintenance.
|
||||
|
||||
The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
|
||||
The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports [eviction](http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
|
||||
|
||||
'drain' waits for graceful termination. You should not operate on the machine until the command completes.
|
||||
|
||||
When you are ready to put the node back into service, use kubectl uncordon, which will make the node schedulable again.
|
||||
|
||||
! http://kubernetes.io/images/docs/kubectl_drain.svg
|
||||
|
||||
|
||||
```
|
||||
kubectl drain NODE
|
||||
|
||||
@@ -9,17 +9,17 @@ Run a proxy to the Kubernetes API server
|
||||
### Synopsis
|
||||
|
||||
|
||||
To proxy all of the kubernetes api and nothing else, use:
|
||||
To proxy all of the Kubernetes api and nothing else, use:
|
||||
|
||||
$ kubectl proxy --api-prefix=/
|
||||
|
||||
To proxy only part of the kubernetes api and also some static files:
|
||||
To proxy only part of the Kubernetes api and also some static files:
|
||||
|
||||
$ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/
|
||||
|
||||
The above lets you 'curl localhost:8001/api/v1/pods'.
|
||||
|
||||
To proxy the entire kubernetes api at a different root, use:
|
||||
To proxy the entire Kubernetes api at a different root, use:
|
||||
|
||||
$ kubectl proxy --api-prefix=/custom/
|
||||
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
---
|
||||
This file is autogenerated, but we've stopped checking such files into the
|
||||
repository to reduce the need for rebases. Please run hack/generate-docs.sh to
|
||||
populate this file.
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
---
|
||||
This file is autogenerated, but we've stopped checking such files into the
|
||||
repository to reduce the need for rebases. Please run hack/generate-docs.sh to
|
||||
populate this file.
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@@ -93,7 +93,7 @@ Due to the implementation of this feature, the source IP for sessions as seen in
|
||||
that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases.
|
||||
|
||||
## Annotation to modify the LoadBalancer behavior for preservation of Source IP
|
||||
In 1.5, an Beta feature has been added that changes the behavior of the external LoadBalancer feature.
|
||||
In 1.5, a Beta feature has been added that changes the behavior of the external LoadBalancer feature.
|
||||
|
||||
This feature can be activated by adding the beta annotation below to the metadata section of the Service Configuration file.
|
||||
|
||||
|
||||
@@ -80,7 +80,7 @@ service "my-nginx-svc" deleted
|
||||
Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`:
|
||||
|
||||
```shell
|
||||
$ kubectl get $(k create -f docs/user-guide/nginx/ -o name | grep service)
|
||||
$ kubectl get $(kubectl create -f docs/user-guide/nginx/ -o name | grep service)
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx-svc 10.0.0.208 80/TCP 0s
|
||||
```
|
||||
@@ -396,7 +396,7 @@ spec:
|
||||
|
||||
The patch is specified using json.
|
||||
|
||||
The system ensures that you don’t clobber changes made by other users or components by confirming that the `resourceVersion` doesn’t differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don’t use your original configuration file as the source since additional fields most likely were set in the live state.
|
||||
The system ensures that you don't clobber changes made by other users or components by confirming that the `resourceVersion` doesn't differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don't use your original configuration file as the source since additional fields most likely were set in the live state.
|
||||
|
||||
For more information, please see [kubectl patch](/docs/user-guide/kubectl/kubectl_patch/) document.
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
|
||||
## Not All Objects are in a Namespace
|
||||
|
||||
Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||
in some namespace. However namespace resources are not themselves in a namespace.
|
||||
And low-level resources, such as [nodes](/docs/admin/node) and
|
||||
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
|
||||
|
||||
@@ -18,7 +18,7 @@ Managing storage is a distinct problem from managing compute. The `PersistentVol
|
||||
|
||||
A `PersistentVolume` (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
|
||||
|
||||
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).
|
||||
A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
|
||||
|
||||
While `PersistentVolumeClaims` allow a user to consume abstract storage
|
||||
resources, it is common that users need `PersistentVolumes` with varying
|
||||
@@ -70,7 +70,7 @@ When a user is done with their volume, they can delete the PVC objects from the
|
||||
|
||||
### Reclaiming
|
||||
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted.
|
||||
The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes, as well as deleting the associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume). Volumes that were dynamically provisioned are always deleted.
|
||||
|
||||
#### Recycling
|
||||
|
||||
@@ -108,6 +108,7 @@ However, the particular path specified in the custom recycler pod template in th
|
||||
* GCEPersistentDisk
|
||||
* AWSElasticBlockStore
|
||||
* AzureFile
|
||||
* AzureDisk
|
||||
* FC (Fibre Channel)
|
||||
* NFS
|
||||
* iSCSI
|
||||
@@ -170,6 +171,7 @@ In the CLI, the access modes are abbreviated to:
|
||||
| :--- | :---: | :---: | :---: |
|
||||
| AWSElasticBlockStore | x | - | - |
|
||||
| AzureFile | x | x | x |
|
||||
| AzureDisk | x | - | - |
|
||||
| CephFS | x | x | x |
|
||||
| Cinder | x | - | - |
|
||||
| FC | x | x | - |
|
||||
@@ -193,15 +195,15 @@ class and can only be bound to PVCs that request no particular class.
|
||||
In the future after beta, the `volume.beta.kubernetes.io/storage-class`
|
||||
annotation will become an attribute.
|
||||
|
||||
### Recycling Policy
|
||||
### Reclaim Policy
|
||||
|
||||
Current recycling policies are:
|
||||
Current reclaim policies are:
|
||||
|
||||
* Retain -- manual reclamation
|
||||
* Recycle -- basic scrub ("rm -rf /thevolume/*")
|
||||
* Delete -- associated storage asset such as AWS EBS, GCE PD or OpenStack Cinder volume is deleted
|
||||
* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted
|
||||
|
||||
Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD and Cinder volumes support deletion.
|
||||
Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion.
|
||||
|
||||
### Phase
|
||||
|
||||
@@ -508,6 +510,24 @@ parameters:
|
||||
* `quobyteConfig`: use the specified configuration to create the volume. You can create a new configuration or modify an existing one with the Web console or the quobyte CLI. Default is "BASE".
|
||||
* `quobyteTenant`: use the specified tenant ID to create/delete the volume. This Quobyte tenant has to be already present in Quobyte. Default is "DEFAULT".
|
||||
|
||||
#### Azure Disk
|
||||
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: storage.k8s.io/v1beta1
|
||||
metadata:
|
||||
name: slow
|
||||
provisioner: kubernetes.io/azure-disk
|
||||
parameters:
|
||||
skuName: Standard_LRS
|
||||
location: eastus
|
||||
storageAccount: azure_storage_account_name
|
||||
```
|
||||
|
||||
* `skuName`: Azure storage account Sku tier. Default is empty.
|
||||
* `location`: Azure storage account location. Default is empty.
|
||||
* `storageAccount`: Azure storage account name. If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, `skuName` and `location` are ignored.
|
||||
|
||||
|
||||
## Writing Portable Configuration
|
||||
|
||||
|
||||
@@ -28,8 +28,8 @@ Throughout this doc you will see a few terms that are sometimes used interchange
|
||||
* Node: A single virtual or physical machine in a Kubernetes cluster.
|
||||
* Cluster: A group of nodes in a single failure domain, unless mentioned otherwise.
|
||||
* Persistent Volume Claim (PVC): A request for storage, typically a [persistent volume](/docs/user-guide/persistent-volumes/walkthrough/).
|
||||
* Host name: The hostname attached to the UTS namespace of the pod, i.e the output of `hostname` in the pod.
|
||||
* DNS/Domain name: A *cluster local* domain name resolvable using standard methods (eg: [gethostbyname](http://linux.die.net/man/3/gethostbyname)).
|
||||
* Host name: The hostname attached to the UTS namespace of the pod, i.e. the output of `hostname` in the pod.
|
||||
* DNS/Domain name: A *cluster local* domain name resolvable using standard methods (e.g.: [gethostbyname](http://linux.die.net/man/3/gethostbyname)).
|
||||
* Ordinality: the property of being "ordinal", or occupying a position in a sequence.
|
||||
* Pet: a single member of a PetSet; more generally, a stateful application.
|
||||
* Peer: a process running a server, capable of communicating with other such processes.
|
||||
@@ -88,7 +88,7 @@ Only use PetSet if your application requires some or all of these properties. Ma
|
||||
|
||||
Example workloads for PetSet:
|
||||
|
||||
* Databases like MySQL or PostgreSQL that require a single instance attached to a NFS persistent volume at any time
|
||||
* Databases like MySQL or PostgreSQL that require a single instance attached to an NFS persistent volume at any time
|
||||
* Clustered software like Zookeeper, Etcd, or Elasticsearch that require stable membership.
|
||||
|
||||
## Alpha limitations
|
||||
@@ -303,7 +303,7 @@ NAME DESIRED CURRENT AGE
|
||||
web 5 5 30m
|
||||
```
|
||||
|
||||
Note however, that scaling up to N and back down to M *will not* delete the volumes of the M-N pets, as described in the section on [deletion](#deleting-a-petset), i.e scaling back up to M creates new pets that use the same volumes. To see this in action, scale the PetSet back down to 3:
|
||||
Note however, that scaling up to N and back down to M *will not* delete the volumes of the M-N pets, as described in the section on [deletion](#deleting-a-petset), i.e. scaling back up to M creates new pets that use the same volumes. To see this in action, scale the PetSet back down to 3:
|
||||
|
||||
```shell
|
||||
$ kubectl get po --watch-only
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user