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

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+3 -1
View File
@@ -7,7 +7,7 @@ weight: 110
{{% capture overview %}}
This page shows how to use a Volume to communicate between two Containers running
in the same Pod.
in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers.
{{% /capture %}}
@@ -141,6 +141,8 @@ the shared Volume is lost.
* See
[Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
* See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+6 -6
View File
@@ -262,12 +262,12 @@ For example:
### Linux
```shell
export KUBECONFIG_SAVED=$KUBECONFIG
export KUBECONFIG_SAVED=$KUBECONFIG
```
### Windows PowerShell
```shell
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
```
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
```
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
@@ -277,7 +277,7 @@ Temporarily append two paths to your `KUBECONFIG` environment variable. For exam
### Linux
```shell
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
```
### Windows PowerShell
```shell
@@ -344,7 +344,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
```
### Windows Powershell
```shell
$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config)
$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config)
```
View configuration information merged from all the files that are now listed
@@ -363,7 +363,7 @@ export KUBECONFIG=$KUBECONFIG_SAVED
```
Windows PowerShell
```shell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
```
{{% /capture %}}
content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+1 -1
View File
@@ -97,7 +97,7 @@ which should produce output like this:
Selector: app=example
Type: LoadBalancer
IP: 10.67.252.103
LoadBalancer Ingress: 123.45.67.89
LoadBalancer Ingress: 192.0.2.89
Port: <unnamed> 80/TCP
NodePort: <unnamed> 32445/TCP
Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+6 -9
View File
@@ -135,8 +135,6 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Create `example-ingress.yaml` from the following file:
```yaml
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
@@ -152,7 +150,6 @@ The following file is an Ingress resource that sends traffic to your Service via
backend:
serviceName: web
servicePort: 8080
```
1. Create the Ingress resource by running the following command:
@@ -232,12 +229,12 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Edit the existing `example-ingress.yaml` and add the following lines:
```yaml
- path: /v2/*
backend:
serviceName: web2
servicePort: 8080
```
```yaml
- path: /v2/*
backend:
serviceName: web2
servicePort: 8080
```
1. Apply the changes:
content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+10 -10
View File
@@ -90,30 +90,30 @@ for database debugging.
## Forward a local port to a port on the pod
1. `kubectl port-forward` allows using resource name, such as a service name, to select a matching pod to port forward to since Kubernetes v1.10.
1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to since Kubernetes v1.10.
kubectl port-forward redis-master-765d459796-258hz 6379:6379
kubectl port-forward redis-master-765d459796-258hz 7000:6379
which is the same as
kubectl port-forward pods/redis-master-765d459796-258hz 6379:6379
kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
or
kubectl port-forward deployment/redis-master 6379:6379
kubectl port-forward deployment/redis-master 7000:6379
or
kubectl port-forward rs/redis-master 6379:6379
kubectl port-forward rs/redis-master 7000:6379
or
kubectl port-forward svc/redis-master 6379:6379
kubectl port-forward svc/redis-master 7000:6379
Any of the above commands works. The output is similar to this:
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
2. Start the Redis command line interface:
@@ -121,7 +121,7 @@ for database debugging.
3. At the Redis command line prompt, enter the `ping` command:
127.0.0.1:6379>ping
127.0.0.1:7000>ping
A successful ping request returns PONG.
@@ -132,7 +132,7 @@ for database debugging.
## Discussion
Connections made to local port 6379 are forwarded to port 6379 of the pod that
Connections made to local port 7000 are forwarded to port 6379 of the pod that
is running the Redis server. With this connection in place you can use your
local workstation to debug the database that is running in the pod.
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
+3 -3
View File
@@ -22,7 +22,7 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
{{< caution >}}
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see ["CA Reusage and Conflicts"][ca-reusage-and-conflicts].
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
{{< /caution >}}
{{< /note >}}
@@ -38,8 +38,8 @@ This section describes how the authentication and authorization flows work, and
The high-level flow is as follows:
1. Kubenetes apiserver: authenticate the requesting user and authorize their rights to the requested API path.
2. Kubenetes apiserver: proxy the request to the extension apiserver
1. Kubernetes apiserver: authenticate the requesting user and authorize their rights to the requested API path.
2. Kubernetes apiserver: proxy the request to the extension apiserver
3. Extension apiserver: authenticate the request from the Kubernetes apiserver
4. Extension apiserver: authorize the request from the original user
5. Extension apiserver: execute
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+1 -1
View File
@@ -175,7 +175,7 @@ that is validated in a Kubernetes e2e test. The webhook handles the
results wrapped in `ConversionResponse`. Note that the request
contains a list of custom resources that need to be converted independently without
changing the order of objects.
The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file]((https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/converter/framework.go)) that leaves only [one function]((https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/converter/example-converter.go#L29-L80)) to be implemented for different conversions.
The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.14.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions.
{{< note >}}
The example conversion webhook server leaves the `ClientAuth` field
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+1 -1
View File
@@ -156,6 +156,7 @@ from the yaml you used to create it:
```console
apiVersion: v1
kind: List
items:
- apiVersion: stable.example.com/v1
kind: CronTab
@@ -170,7 +171,6 @@ items:
spec:
cronSpec: '* * * * */5'
image: my-awesome-cron-image
kind: List
metadata:
resourceVersion: ""
selfLink: ""
content/en/docs/tasks/administer-cluster/access-cluster-api.md
+4 -4
View File
@@ -123,10 +123,10 @@ The output is similar to this:
Using `jsonpath` approach:
```
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```shell
APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
{
"kind": "APIVersions",
"versions": [
content/en/docs/tasks/administer-cluster/cluster-management.md
+4 -2
View File
@@ -26,8 +26,6 @@ To install Kubernetes on a set of machines, consult one of the existing [Getting
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
* [Upgrading to 1.6](/docs/admin/upgrade-1-6)
### Upgrading an Azure Kubernetes Service (AKS) cluster
Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
@@ -79,6 +77,8 @@ Different providers, and tools, will manage upgrades differently. It is recomme
* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
* ...
To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the [Skewed versions](docs/setup/version-skew-policy/#supported-component-upgrade-order) page.
## Resizing a cluster
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
@@ -219,3 +219,5 @@ kubectl convert -f pod.yaml --output-version v1
```
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
{{% /capture %}}
content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md
+1 -1
View File
@@ -34,7 +34,7 @@ in the Kubernetes source directory for a canonical example.
Package your scheduler binary into a container image. For the purposes of this example,
let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
and build the source.
```shell
content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+1 -1
View File
@@ -120,7 +120,7 @@ Though etcd keeps unique member IDs internally, it is recommended to use a uniqu
The following message is displayed:
8211f1d0f64f3269, started, member1, http://10.0.0.1:12380, http://10.0.0.1:2379
8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379
91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379
fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
content/en/docs/tasks/administer-cluster/declare-network-policy.md
+1 -1
View File
@@ -90,8 +90,8 @@ Connecting to nginx (10.100.0.16:80)
Let's say you want to limit access to the `nginx` service so that only pods with the label `access: true` can query it. To do that, create a `NetworkPolicy` that allows connections only from those pods:
```yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-nginx
spec:
content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+2 -2
View File
@@ -12,7 +12,7 @@ content_template: templates/concept
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
In upcoming releases, Cloud Controller Manager will
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
can develop their features independently from the core Kubernetes release cycles.**
can develop their features independently from the core Kubernetes release cycles.
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
@@ -33,7 +33,7 @@ To build an out-of-tree cloud-controller-manager for your cloud, follow these st
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go).
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52).
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go).
Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+2 -2
View File
@@ -9,7 +9,7 @@ content_template: templates/task
{{% capture overview %}}
This page explains how to configure your DNS Pod and customize the
DNS resolution process. In Kubernetes version 1.11 and later, CoreDNS is at GA
and is installed by default with kubeadm. See [Configuring CoreDNS](#config-coredns)
and is installed by default with kubeadm. See [CoreDNS ConfigMap options](#coredns-configmap-options)
and [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/).
{{% /capture %}}
@@ -162,7 +162,7 @@ During translation, all FQDN nameservers will be omitted from the CoreDNS config
## Kube-dns
Kube-dns is now available as a optional DNS server since CoreDNS is now the default.
Kube-dns is now available as an optional DNS server since CoreDNS is now the default.
The running DNS Pod holds 3 containers:
- "`kubedns`": watches the Kubernetes master for changes
content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+37 -14
View File
@@ -12,6 +12,8 @@ Kubernetes cluster.
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* This guide assumes your nodes use the AMD64 or Intel 64 CPU architecture
* Make sure the [DNS feature](/docs/concepts/services-networking/dns-pod-service/) itself is enabled.
* Kubernetes version 1.4.0 or later is recommended.
@@ -22,9 +24,12 @@ Kubernetes cluster.
## Determining whether DNS horizontal autoscaling is already enabled
List the Deployments in your cluster in the kube-system namespace:
List the {{< glossary_tooltip text="Deployments" term_id="deployment" >}}
in your cluster in the kube-system namespace:
kubectl get deployment --namespace=kube-system
```shell
kubectl get deployment --namespace=kube-system
```
The output is similar to this:
@@ -41,7 +46,9 @@ already enabled, and you can skip to
List the Deployments in your cluster in the kube-system namespace:
kubectl get deployment --namespace=kube-system
```shell
kubectl get deployment --namespace=kube-system
```
The output is similar to this:
@@ -58,7 +65,9 @@ ReplicationController instead of a Deployment. So if you don't see kube-dns,
or a similar name, in the preceding output, list the ReplicationControllers in
your cluster in the kube-system namespace:
kubectl get rc --namespace=kube-system
```shell
kubectl get rc --namespace=kube-system
```
The output is similar to this:
@@ -98,7 +107,9 @@ In the file, replace `<SCALE_TARGET>` with your scale target.
Go to the directory that contains your configuration file, and enter this
command to create the Deployment:
kubectl apply -f dns-horizontal-autoscaler.yaml
```shell
kubectl apply -f dns-horizontal-autoscaler.yaml
```
The output of a successful command is:
@@ -108,9 +119,11 @@ DNS horizontal autoscaling is now enabled.
## Tuning autoscaling parameters
Verify that the dns-autoscaler ConfigMap exists:
Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists:
kubectl get configmap --namespace=kube-system
```shell
kubectl get configmap --namespace=kube-system
```
The output is similar to this:
@@ -121,11 +134,15 @@ The output is similar to this:
Modify the data in the ConfigMap:
kubectl edit configmap dns-autoscaler --namespace=kube-system
```shell
kubectl edit configmap dns-autoscaler --namespace=kube-system
```
Look for this line:
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
```yaml
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
```
Modify the fields according to your needs. The "min" field indicates the
minimal number of DNS backends. The actual number of backends number is
@@ -152,7 +169,9 @@ use depends on different conditions.
This option works for all situations. Enter this command:
kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
```shell
kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
```
The output is:
@@ -160,7 +179,9 @@ The output is:
Verify that the replica count is zero:
kubectl get deployment --namespace=kube-system
```shell
kubectl get deployment --namespace=kube-system
```
The output displays 0 in the DESIRED and CURRENT columns:
@@ -174,7 +195,9 @@ The output displays 0 in the DESIRED and CURRENT columns:
This option works if dns-autoscaler is under your own control, which means
no one will re-create it:
kubectl delete deployment dns-autoscaler --namespace=kube-system
```shell
kubectl delete deployment dns-autoscaler --namespace=kube-system
```
The output is:
@@ -182,7 +205,7 @@ The output is:
### Option 3: Delete the dns-autoscaler manifest file from the master node
This option works if dns-autoscaler is under control of the
This option works if dns-autoscaler is under control of the (deprecated)
[Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md),
and you have write access to the master node.
@@ -235,6 +258,6 @@ is under consideration as a future development.
{{% /capture %}}
{{% capture whatsnext %}}
Learn more about the
* Learn more about the
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
{{% /capture %}}
content/en/docs/tasks/administer-cluster/encrypt-data.md
+13 -3
View File
@@ -33,8 +33,8 @@ The alpha version of the encryption feature prior to 1.13 used the `--experiment
## Understanding the encryption at rest configuration.
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -92,13 +92,23 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
is the first provider, the first key is used for encryption.
__Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption
creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the
kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than
locally-stored encryption keys.
## Encrypting your data
Create a new encryption config file:
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -190,8 +200,8 @@ With a single `kube-apiserver`, step 2 may be skipped.
To disable encryption at rest place the `identity` provider as the first entry in the config:
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
+6 -2
View File
@@ -16,6 +16,9 @@ A cluster may stop working properly if a critical add-on is evicted (either manu
and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space
vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).
Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable.
For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled.
{{% /capture %}}
@@ -24,9 +27,10 @@ vacated by the evicted critical add-on pod or the amount of resources available
### Marking pod as critical
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
Prior to v1.11, critical pod has to run in the `kube-system` namespace, this restriction was removed after v1.11 and pod in any namespace can be configed as a critical pod by the following either way:
* Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.
* Ensure the PodPriority [feature gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) is enabled. Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster, the two priority class names available since v1.10+
* Alternatively, ensure both PodPriority and ExperimentalCriticalPodAnnotation feature gates are enabled, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in a future release.
{{% /capture %}}
content/en/docs/tasks/administer-cluster/highly-available-master.md
+1 -1
View File
@@ -107,7 +107,7 @@ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up
* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
To survive zone failure, also place nodes in multiple zones
(see [multiple-zones](/docs/setup/multiple-zones/) for details).
(see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
content/en/docs/tasks/administer-cluster/kms-provider.md
+3 -3
View File
@@ -80,8 +80,8 @@ To encrypt the data:
1. Create a new encryption configuration file using the appropriate properties for the `kms` provider:
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -136,8 +136,8 @@ To switch from a local encryption provider to the `kms` provider and re-encrypt
1. Add the `kms` provider as the first entry in the configuration file as shown in the following example.
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -166,8 +166,8 @@ To disable encryption at rest:
1. Place the `identity` provider as the first entry in the configuration file:
```yaml
kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+22 -16
View File
@@ -17,7 +17,7 @@ Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/k
Be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
Have a working Kubernetes cluster installed using kubeadm with your certificates stored in `/etc/kubernetes/pki` folder; in case you are using a different location, the following can be adapted accordingly.
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
{{% /capture %}}
@@ -89,7 +89,7 @@ If you are running an HA cluster, this command needs to be executed on all the c
`kubeadm alpha certs renew` provides the following options:
- `--use-api` allows you to use the Kubernetes certificates API for signing certificates (instead of the local CA/front-proxy-CA); see next paragraphs for more information.
The Kubernetes certificates normally reach their expiration date after one year.
- `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
@@ -105,8 +105,10 @@ These are advanced topics for users who need to integrate their organization's c
### Set up a signer
The Kubernetes Certificate Authority does not work out of the box.
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
The Kubernetes Certificate Authority does not work out of the box.
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
The built-in signer is part of [`kube-controller-manager`][kcm].
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
The built-in signer is part of [`kube-controller-manager`][kcm].
@@ -131,7 +133,9 @@ If you're creating a new cluster, you can use a kubeadm [configuration file][con
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`.
The command outputs the name of the certificate to approve, then blocks and waits for approval to occur. e.g.:
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
```shell
sudo kubeadm alpha certs renew apiserver --use-api &
@@ -162,13 +166,15 @@ You can view a list of pending certificates with `kubectl get csr`.
This section provide more details about how to execute manual certificate renewal using an external CA.
{{< caution >}}
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
{{< /caution >}}
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
A CSR represents a request to a CA for a signed certificate for a client.
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
### Create certificate signing requests (CSR)
To better integrate with external CAs, kubeadm can produce certificate signing requests (CSRs).
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
A CSR represents a request to a CA for a signed certificate for a client.
@@ -176,10 +182,13 @@ You can create certificate signing requests with `kubeadm alpha certs renew --cs
Both the CSR and the accompanying private key are given in the output; you can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
### Renew certificates
Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
A CSR contains a certificate's name, domain(s), and IPs, but it does not specify usages.
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
@@ -189,11 +198,8 @@ After a certificate is signed using your preferred method, the certificate and t
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
[certs]: /docs/setup/certificates
[cert-cas]: /docs/setup/certificates/#single-root-ca
[cert-table]: /docs/setup/certificates/#all-certificates
[manage-tls]: /docs/tasks/tls/managing-tls-in-a-cluster/
[cert-manager]: https://github.com/jetstack/cert-manager
[certs]: /docs/reference/generated/kubectl/kubectl-commands#certificate
[certs]: /docs/setup/best-practices/certificates/
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
{{% /capture %}}
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md.orig
+205
View File
@@ -0,0 +1,205 @@
---
reviewers:
- sig-cluster-lifecycle
title: Certificate Management with kubeadm
content_template: templates/task
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm.
{{% /capture %}}
{{% capture prerequisites %}}
Be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/certificates/).
You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/).
{{% /capture %}}
{{% capture steps %}}
## Check certificate expiration
`check-expiration` can be used to check certificate expiration.
```
kubeadm alpha certs check-expiration
```
The output is similar to this:
```
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf May 15, 2020 13:03 UTC 364d false
apiserver May 15, 2020 13:00 UTC 364d false
apiserver-etcd-client May 15, 2020 13:00 UTC 364d false
apiserver-kubelet-client May 15, 2020 13:00 UTC 364d false
controller-manager.conf May 15, 2020 13:03 UTC 364d false
etcd-healthcheck-client May 15, 2020 13:00 UTC 364d false
etcd-peer May 15, 2020 13:00 UTC 364d false
etcd-server May 15, 2020 13:00 UTC 364d false
front-proxy-client May 15, 2020 13:00 UTC 364d false
scheduler.conf May 15, 2020 13:03 UTC 364d false
```
The command shows expiration/residual time for the client certificates in the `/etc/kubernetes/pki` folder and for the client certificate embedded in the KUBECONFIG files used by kubeadm (`admin.conf`, `controller-manager.conf` and `scheduler.conf`).
Additionally, kubeadm informs the user if the certificate is externally managed; in this case, the user should take care of managing certificate renewal manually/using other tools.
{{< warning >}}
`kubeadm` cannot manage certificates signed by an external CA.
{{< /warning >}}
{{< note >}}
`kubelet.conf` is not included in the list above because kubeadm configures kubelet for automatic certificate renewal.
{{< /note >}}
## Automatic certificate renewal
`kubeadm` renews all the certificates during control plane [upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/).
This feature is designed for addressing the simplest use cases;
if you don't have specific requirements on certificate renewal and perform Kubernetes version upgrades regularly (less than 1 year in between each upgrade), kubeadm will take care of keeping your cluster up to date and reasonably secure.
{{< note >}}
It is a best practice to upgrade your cluster frequently in order to stay secure.
{{< /note >}}
If you have more complex requirements for certificate renewal, you can opt out from the default behavior by passing `--certificate-renewal=false` to `kubeadm upgrade apply` or to `kubeadm upgrade node`.
## Manual certificate renewal
You can renew your certificates manually at any time with the `kubeadm alpha certs renew` command.
This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
{{< warning >}}
If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
{{< /warning >}}
{{< note >}}
`alpha certs renew` uses the existing certificates as the authoritative source for attributes (Common Name, Organization, SAN, etc.) instead of the kubeadm-config ConfigMap. It is strongly recommended to keep them both in sync.
{{< /note >}}
`kubeadm alpha certs renew` provides the following options:
The Kubernetes certificates normally reach their expiration date after one year.
- `--csr-only` can be used to renew certificats with an external CA by generating certificate signing requests (without actually renewing certificates in place); see next paragraph for more information.
- It's also possible to renew a single certificate instead of all.
## Renew certificates with the Kubernetes certificates API
This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API.
{{< caution >}}
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
{{< /caution >}}
### Set up a signer
The Kubernetes Certificate Authority does not work out of the box.
You can configure an external signer such as [cert-manager][cert-manager-issuer], or you can use the build-in signer.
The built-in signer is part of [`kube-controller-manager`][kcm].
To activate the build-in signer, you pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` arguments.
The built-in signer is part of [`kube-controller-manager`][kcm].
To activate the build-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags.
If you're creating a new cluster, you can use a kubeadm [configuration file][config]:
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
```
[cert-manager-issuer]: https://cert-manager.readthedocs.io/en/latest/tutorials/ca/creating-ca-issuer.html
[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
### Create certificate signing requests (CSR)
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm alpha certs renew --use-api`.
If you set up an external signer such as [cert-manager][cert-manager], certificate signing requests (CSRs) are automatically approved.
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command.
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
```shell
sudo kubeadm alpha certs renew apiserver --use-api &
```
The output is similar to this:
```
[1] 2890
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
```
### Approve certificate signing requests (CSR)
If you set up an external signer, certificate signing requests (CSRs) are automatically approved.
Otherwise, you must manually approve certificates with the [`kubectl certificate`][certs] command. e.g.
```shell
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
```
The output is similar to this:
```shell
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
```
You can view a list of pending certificates with `kubectl get csr`.
## Renew certificates with external CA
This section provide more details about how to execute manual certificate renewal using an external CA.
To better integrate with external CAs, kubeadm can also produce certificate signing requests (CSRs).
A CSR represents a request to a CA for a signed certificate for a client.
In kubeadm terms, any certificate that would normally be signed by an on-disk CA can be produced as a CSR instead. A CA, however, cannot be produced as a CSR.
### Create certificate signing requests (CSR)
You can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
If `--csr-dir` is not specified, the default certificate directory (`/etc/kubernetes/pki`) is used.
Both the CSR and the accompanying private key are given in the output. After a certificate is signed, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
A CSR represents a request to a CA for a signed certificate for a client.
You can create certificate signing requests with `kubeadm alpha certs renew --csr-only`.
Both the CSR and the accompanying private key are given in the output; you can pass in a directory with `--csr-dir` to output the CSRs to the specified location.
Certificates can be renewed with `kubeadm alpha certs renew --csr-only`.
As with `kubeadm init`, an output directory can be specified with the `--csr-dir` flag.
To use the new certificates, copy the signed certificate and private key into the PKI directory (by default `/etc/kubernetes/pki`)
A CSR contains a certificate's name, domain(s), and IPs, but it does not specify usages.
A CSR contains a certificate's name, domains, and IPs, but it does not specify usages.
It is the responsibility of the CA to specify [the correct cert usages][cert-table] when issuing a certificate.
* In `openssl` this is done with the [`openssl ca` command][openssl-ca].
* In `cfssl` you specify [usages in the config file][cfssl-usages]
After a certificate is signed using your preferred method, the certificate and the private key must be copied to the PKI directory (by default `/etc/kubernetes/pki`).
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
[certs]: /docs/setup/best-practices/certificates/
[cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca
[cert-table]: /docs/setup/best-practices/certificates/#all-certificates
{{% /capture %}}
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13.md
+2
View File
@@ -285,8 +285,10 @@ A possible workaround is described [here](https://github.com/kubernetes/kubeadm/
{{< tabs name="k8s_kubelet_and_kubeadm" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.13.x-00 with the latest patch version
apt-mark unhold kubelet kubeadm
apt-get update
apt-get install -y kubelet=1.13.x-00 kubeadm=1.13.x-00
apt-mark hold kubelet kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.13.x-0 with the latest patch version
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14.md
+7 -11
View File
@@ -228,9 +228,9 @@ are merged into a single document.
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.14.x-00 with the latest patch version
apt-mark unhold kubelet && \
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.14.x-00 kubectl=1.14.x-00 && \
apt-mark hold kubelet
apt-mark hold kubelet kubectl
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.14.x-0 with the latest patch version
@@ -260,7 +260,7 @@ sudo kubeadm upgrade apply
Also `sudo kubeadm upgrade plan` is not needed.
## Ugrade worker nodes
## Upgrade worker nodes
The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
without compromising the minimum required capacity for running your workloads.
@@ -290,16 +290,12 @@ without compromising the minimum required capacity for running your workloads.
kubectl drain $NODE --ignore-daemonsets
```
You should see output similar to this:
You should see output similar to this:
```shell
kubectl drain ip-172-31-85-18
node "ip-172-31-85-18" cordoned
error: unable to drain node "ip-172-31-85-18", aborting command...
There are pending nodes to be drained:
ip-172-31-85-18
error: DaemonSet-managed pods (use --ignore-daemonsets to ignore): calico-node-5798d, kube-proxy-thjp9
node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained
```
### Upgrade the kubelet config
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13.md
+1 -1
View File
@@ -9,7 +9,7 @@ content_template: templates/task
{{% capture overview %}}
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/independent/high-availability/).
This page explains how to upgrade a highly available (HA) Kubernetes cluster created with `kubeadm` from version 1.12.x to version 1.13.y. In addition to upgrading, you must also follow the instructions in [Creating HA clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/).
{{% /capture %}}
content/en/docs/tasks/administer-cluster/kubelet-config-file.md
+2 -2
View File
@@ -30,15 +30,15 @@ it simplifies node deployment and configuration management.
The subset of the Kubelet's configuration that can be configured via a file
is defined by the `KubeletConfiguration` struct
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/config/types.go).
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
The configuration file must be a JSON or YAML representation of the parameters
in this struct. Make sure the Kubelet has read permissions on the file.
Here is an example of what this file might look like:
```
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
memory.available: "200Mi"
```
content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md
+4
View File
@@ -273,8 +273,12 @@ kubectl get deployment
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
cattle 5 5 5 5 10s
```
```shell
kubectl get pods -l run=cattle
```
```
NAME READY STATUS RESTARTS AGE
cattle-2263376956-41xy6 1/1 Running 0 34s
cattle-2263376956-kw466 1/1 Running 0 34s
content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+1 -1
View File
@@ -45,7 +45,7 @@ DaemonSet configurations for Cilium, and the necessary configurations to connect
to the etcd instance deployed in minikube as well as appropriate RBAC settings:
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
```
```
configmap/cilium-config created
content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+1 -1
View File
@@ -36,7 +36,7 @@ To apply network policies use one of the following:
{{% capture whatsnext %}}
Once your have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
{{% /capture %}}
content/en/docs/tasks/administer-cluster/out-of-resource.md
+1 -1
View File
@@ -140,7 +140,7 @@ The `kubelet` has the following default hard eviction threshold:
The `kubelet` evaluates eviction thresholds per its configured housekeeping interval.
* `housekeeping-interval` is the interval between container housekeepings.
* `housekeeping-interval` is the interval between container housekeepings which defaults to `10s`.
### Node Conditions
content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+3 -3
View File
@@ -149,9 +149,6 @@ This is an example of a valid response:
```none
apiVersion: v1
data:
kubelet: |
{...}
kind: ConfigMap
metadata:
creationTimestamp: 2017-09-14T20:23:33Z
@@ -160,6 +157,9 @@ metadata:
resourceVersion: "119980"
selfLink: /api/v1/namespaces/kube-system/configmaps/my-node-config-gkt4c2m4b2
uid: 946d785e-998a-11e7-a8dd-42010a800006
data:
kubelet: |
{...}
```
The ConfigMap is created in the `kube-system` namespace because this
content/en/docs/tasks/administer-cluster/safely-drain-node.md
+6 -8
View File
@@ -4,13 +4,12 @@ reviewers:
- mml
- foxish
- kow3ns
title: Safely Drain a Node while Respecting Application SLOs
title: Safely Drain a Node while Respecting the PodDisruptionBudget
content_template: templates/task
---
{{% capture overview %}}
This page shows how to safely drain a machine, respecting the application-level
disruption SLOs you have specified using PodDisruptionBudget.
This page shows how to safely drain a machine, respecting the PodDisruptionBudget you have defined.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -46,11 +45,10 @@ documentation for more details.
When `kubectl drain` returns successfully, that indicates that all of
the pods (except the ones excluded as described in the previous paragraph)
have been safely evicted (respecting the desired graceful
termination period, and without violating any application-level
disruption SLOs). It is then safe to bring down the node by powering
down its physical machine or, if running on a cloud platform, deleting its
virtual machine.
have been safely evicted (respecting the desired graceful termination period,
and respecting the PodDisruptionBudget you have defined). It is then safe to
bring down the node by powering 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
content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+3 -2
View File
@@ -9,7 +9,8 @@ content_template: templates/task
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
This document describes how to configure and use kernel parameters within a
Kubernetes cluster using the sysctl interface.
Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}}
interface.
{{% /capture %}}
@@ -80,7 +81,7 @@ kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.ipv4.route.min_pmtu' ...
```
For minikube, this can be done via the `extra-config` flag:
For {{< glossary_tooltip term_id="minikube" >}}, this can be done via the `extra-config` flag:
```shell
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+1 -1
View File
@@ -305,7 +305,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example
If you do not specify a memory limit for a Container, one of the following situations applies:
* The Container has no upper bound on the amount of memory it uses. The Container
could use all of the memory available on the Node where it is running.
could use all of the memory available on the Node where it is running which in turn could invoke the OOM Killer. Further, in case of an OOM Kill, a container with no resource limits will have a greater chance of being killed.
* The Container is running in a namespace that has a default memory limit, and the
Container is automatically assigned the default limit. Cluster administrators can use a
content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+2 -2
View File
@@ -102,8 +102,8 @@ A cluster role needs to be defined for each GMSA credential spec resource. This
```
#Create the Role to read the credspec
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: webapp1-role
rules:
@@ -117,8 +117,8 @@ rules:
A service account (that pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to "use" the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.
```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: allow-default-svc-account-read-on-gmsa-WebApp1
namespace: default
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+5 -1
View File
@@ -138,7 +138,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
other code indicates failure.
You can see the source code for the server in
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go).
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
For the first 10 seconds that the Container is alive, the `/healthz` handler
returns a status of 200. After that, the handler returns a status of 500.
@@ -310,6 +310,10 @@ and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should
to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common
case, you should not use `host`, but rather set the `Host` header in `httpHeaders`.
For a probe, the kubelet makes the probe connection at the node, not in the pod, which
means that you can not use a service name in the `host` parameter since the kubelet is unable
to resolve it.
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+3 -3
View File
@@ -41,11 +41,11 @@ shell to your Node by entering `minikube ssh`.
In your shell, create a `/mnt/data` directory:
mkdir /mnt/data
sudo mkdir /mnt/data
In the `/mnt/data` directory, create an `index.html` file:
echo 'Hello from Kubernetes storage' > /mnt/data/index.html
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
## Create a PersistentVolume
@@ -175,8 +175,8 @@ PersistentVolume.
Use the `pv.beta.kubernetes.io/gid` annotation as follows:
```yaml
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
annotations:
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
+46 -48
View File
@@ -54,8 +54,8 @@ For example:
mkdir -p configure-pod-container/configmap/
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://k8s.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://k8s.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# Create the configmap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
@@ -96,6 +96,14 @@ The output is similar to this:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
game.properties: |
enemies=aliens
@@ -110,14 +118,6 @@ data:
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
```
#### Create ConfigMaps from files
@@ -186,7 +186,7 @@ Use the option `--from-env-file` to create a ConfigMap from an env-file, for exa
# There is no special handling of quotation marks (i.e. they will be part of the ConfigMap value)).
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://k8s.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
# The env-file `game-env-file.properties` looks like below
cat configure-pod-container/configmap/game-env-file.properties
@@ -211,10 +211,6 @@ kubectl get configmap game-config-env-file -o yaml
where the output is similar to this:
```yaml
apiVersion: v1
data:
allowed: '"true"'
enemies: aliens
lives: "3"
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:36:28Z
@@ -223,6 +219,10 @@ metadata:
resourceVersion: "809965"
selfLink: /api/v1/namespaces/default/configmaps/game-config-env-file
uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
allowed: '"true"'
enemies: aliens
lives: "3"
```
When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used:
@@ -246,10 +246,6 @@ kubectl get configmap config-multi-env-files -o yaml
where the output is similar to this:
```yaml
apiVersion: v1
data:
color: purple
how: fairlyNice
textmode: "true"
kind: ConfigMap
metadata:
creationTimestamp: 2017-12-27T18:38:34Z
@@ -258,6 +254,10 @@ metadata:
resourceVersion: "810136"
selfLink: /api/v1/namespaces/default/configmaps/config-multi-env-files
uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
color: purple
how: fairlyNice
textmode: "true"
```
#### Define the key to use when creating a ConfigMap from a file
@@ -284,6 +284,14 @@ kubectl get configmaps game-config-3 -o yaml
where the output is similar to this:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
game-special-key: |
enemies=aliens
@@ -293,14 +301,6 @@ data:
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
```
#### Create ConfigMaps from literal values
@@ -320,9 +320,6 @@ kubectl get configmaps special-config -o yaml
The output is similar to this:
```yaml
apiVersion: v1
data:
special.how: very
special.type: charm
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
@@ -331,6 +328,9 @@ metadata:
resourceVersion: "651"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm
```
### Create a ConfigMap from generator
@@ -446,10 +446,10 @@ configmap/special-config-2-c92b5mmcf2 created
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-single-configmap-env-variable.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
```
Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`.
Now, the Pod's output includes environment variable `SPECIAL_LEVEL_KEY=very`.
### Define container environment variables with data from multiple ConfigMaps
@@ -460,7 +460,7 @@ configmap/special-config-2-c92b5mmcf2 created
Create the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/configmap/configmaps.yaml
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
```
* Define the environment variables in the Pod specification.
@@ -470,10 +470,10 @@ configmap/special-config-2-c92b5mmcf2 created
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-multiple-configmap-env-variable.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
```
Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`.
Now, the Pod's output includes environment variables `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`.
## Configure all key-value pairs in a ConfigMap as container environment variables
@@ -488,7 +488,7 @@ This functionality is available in Kubernetes v1.6 and later.
Create the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/configmap/configmap-multikeys.yaml
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
* Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
@@ -498,10 +498,10 @@ This functionality is available in Kubernetes v1.6 and later.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-configmap-envFrom.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
```
Now, the Pod's output includes `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
## Use ConfigMap-defined environment variables in Pod commands
@@ -515,7 +515,7 @@ For example, the following Pod specification
created by running
```shell
kubectl create -f https://k8s.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
```
produces the following output in the `test-container` container:
@@ -535,7 +535,7 @@ The examples in this section refer to a ConfigMap named special-config, shown be
Create the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/configmap/configmap-multikeys.yaml
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
### Populate a Volume with data stored in a ConfigMap
@@ -549,14 +549,14 @@ The `command` section references the `special.level` item stored in the ConfigMa
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-configmap-volume.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
```
When the pod runs, the command `ls /etc/config/` produces the output below:
```shell
special.level
special.type
SPECIAL_LEVEL
SPECIAL_TYPE
```
{{< caution >}}
@@ -566,14 +566,14 @@ If there are some files in the `/etc/config/` directory, they will be deleted.
### Add ConfigMap data to a specific path in the Volume
Use the `path` field to specify the desired file path for specific ConfigMap items.
In this case, the `special.level` item will be mounted in the `config-volume` volume at `/etc/config/keys`.
In this case, the `SPECIAL_LEVEL` item will be mounted in the `config-volume` volume at `/etc/config/keys`.
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/pod-configmap-volume-specific-key.yaml
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
```
When the pod runs, the command `cat /etc/config/keys` produces the output below:
@@ -610,8 +610,8 @@ ConfigMaps should reference properties files, not replace them. Think of the Con
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
```yaml
kind: ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
@@ -658,5 +658,3 @@ data:
{{% /capture %}}
`
content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+39 -26
View File
@@ -8,7 +8,7 @@ weight: 70
---
{{% capture overview %}}
This page shows how to use a [`projected`](/docs/concepts/storage/volumes/#projected) volume to mount
This page shows how to use a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount
several existing volume sources into the same directory. Currently, `secret`, `configMap`, `downwardAPI`,
and `serviceAccountToken` volumes can be projected.
@@ -24,49 +24,62 @@ and `serviceAccountToken` volumes can be projected.
{{% capture steps %}}
## Configure a projected volume for a pod
In this exercise, you create username and password Secrets from local files. You then create a Pod that runs one Container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory.
In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files. You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory.
Here is the configuration file for the Pod:
{{< codenew file="pods/storage/projected.yaml" >}}
1. Create the Secrets:
```shell
```shell
# Create files containing the username and password:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt
# Package these files into secrets:
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt
```
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt
```
1. Create the Pod:
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
```
1. Verify that the Pod's Container is running, and then watch for changes to
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
```
1. Verify that the Pod's container is running, and then watch for changes to
the Pod:
```shell
kubectl get --watch pod test-projected-volume
```
```shell
kubectl get --watch pod test-projected-volume
```
The output looks like this:
```shell
NAME READY STATUS RESTARTS AGE
test-projected-volume 1/1 Running 0 14s
```
1. In another terminal, get a shell to the running Container:
```shell
kubectl exec -it test-projected-volume -- /bin/sh
```
```
NAME READY STATUS RESTARTS AGE
test-projected-volume 1/1 Running 0 14s
```
1. In another terminal, get a shell to the running container:
```shell
kubectl exec -it test-projected-volume -- /bin/sh
```
1. In your shell, verify that the `projected-volume` directory contains your projected sources:
```shell
ls /projected-volume/
```
## Clean up
Delete the Pod and the Secrets:
```shell
ls /projected-volume/
kubectl delete pod test-projected-volume
kubectl delete secret user pass
```
{{% /capture %}}
{{% capture whatsnext %}}
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
+5 -4
View File
@@ -131,13 +131,13 @@ The output is similar to this:
```yaml
apiVersion: v1
data:
.dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
kind: Secret
metadata:
...
name: regcred
...
data:
.dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
type: kubernetes.io/dockerconfigjson
```
@@ -153,7 +153,7 @@ kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base
The output is similar to this:
```json
{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
```
To understand what is in the `auth` field, convert the base64-encoded data to a readable format:
@@ -187,7 +187,7 @@ wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yam
In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the path to an image in a private registry such as:
```none
janedoe/jdoe-private:v1
your.private.registry.example.com/janedoe/jdoe-private:v1
```
To pull the image from the private registry, Kubernetes needs credentials.
@@ -206,6 +206,7 @@ kubectl get pod private-reg
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
* Learn more about [adding image pull secrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account).
* See [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-).
* See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
content/en/docs/tasks/configure-pod-container/security-context.md
+4 -4
View File
@@ -79,15 +79,15 @@ kubectl exec -it security-context-demo -- sh
In your shell, list the running processes:
```shell
ps aux
ps
```
The output shows that the processes are running as user 1000, which is the value of `runAsUser`:
```shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 1 0.0 0.0 4336 724 ? Ss 18:16 0:00 /bin/sh -c node server.js
1000 5 0.2 0.6 772124 22768 ? Sl 18:16 0:00 node server.js
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
6 1000 0:00 sh
...
```
content/en/docs/tasks/configure-pod-container/share-process-namespace.md
+35 -29
View File
@@ -43,52 +43,58 @@ Process Namespace Sharing is enabled using the `ShareProcessNamespace` field of
1. Create the pod `nginx` on your cluster:
kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
```shell
kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
```
1. Attach to the `shell` container and run `ps`:
```
kubectl attach -it nginx -c shell
```
```shell
kubectl attach -it nginx -c shell
```
If you don't see a command prompt, try pressing enter.
If you don't see a command prompt, try pressing enter.
```
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
14 101 0:00 nginx: worker process
15 root 0:00 sh
21 root 0:00 ps ax
```
```
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
14 101 0:00 nginx: worker process
15 root 0:00 sh
21 root 0:00 ps ax
```
You can signal processes in other containers. For example, send `SIGHUP` to
nginx to restart the worker process. This requires the `SYS_PTRACE` capability.
/ # kill -HUP 8
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
15 root 0:00 sh
22 101 0:00 nginx: worker process
23 root 0:00 ps ax
```
/ # kill -HUP 8
/ # ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
15 root 0:00 sh
22 101 0:00 nginx: worker process
23 root 0:00 ps ax
```
It's even possible to access another container image using the
`/proc/$pid/root` link.
/ # head /proc/8/root/etc/nginx/nginx.conf
```
/ # head /proc/8/root/etc/nginx/nginx.conf
user nginx;
worker_processes 1;
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
events {
worker_connections 1024;
```
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+3 -3
View File
@@ -102,7 +102,7 @@ you need is an existing `docker-compose.yml` file.
- "6379"
redis-slave:
image: gcr.io/google_samples/gb-redisslave:v1
image: gcr.io/google_samples/gb-redisslave:v3
ports:
- "6379"
environment:
@@ -177,7 +177,7 @@ you need is an existing `docker-compose.yml` file.
Selector: service=frontend
Type: LoadBalancer
IP: 10.0.0.183
LoadBalancer Ingress: 123.45.67.89
LoadBalancer Ingress: 192.0.2.89
Port: 80 80/TCP
NodePort: 80 31144/TCP
Endpoints: 172.17.0.4:80
@@ -189,7 +189,7 @@ you need is an existing `docker-compose.yml` file.
If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.
```sh
$ curl http://123.45.67.89
$ curl http://192.0.2.89
```
{{% /capture %}}
content/en/docs/tasks/debug-application-cluster/audit.md
+9 -8
View File
@@ -345,8 +345,8 @@ Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluent
1. create a config file for fluentd
```none
$ cat <<'EOF' > /etc/fluentd/config
```
cat <<'EOF' > /etc/fluentd/config
# fluentd conf runs in the same host with kube-apiserver
<source>
@type tail
@@ -401,7 +401,7 @@ Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluent
1. start fluentd
```shell
$ fluentd -c /etc/fluentd/config -vv
fluentd -c /etc/fluentd/config -vv
```
1. start kube-apiserver with the following options:
@@ -419,10 +419,11 @@ we will use logstash to collect audit events from webhook backend, and save even
different users into different files.
1. install [logstash][logstash_install_doc]
1. create config file for logstash
```none
$ cat <<EOF > /etc/logstash/config
```
cat <<EOF > /etc/logstash/config
input{
http{
#TODO, figure out a way to use kubeconfig file to authenticate to logstash
@@ -454,13 +455,14 @@ different users into different files.
1. start logstash
```shell
$ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
```
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
$ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
apiVersion: v1
kind: Config
clusters:
- cluster:
server: http://<ip_of_logstash>:8888
@@ -471,7 +473,6 @@ different users into different files.
user: ""
name: default-context
current-context: default-context
kind: Config
preferences: {}
users: []
EOF
content/en/docs/tasks/debug-application-cluster/debug-service.md
+3 -3
View File
@@ -48,10 +48,10 @@ OUTPUT
## Running commands in a Pod
For many steps here you will want to see what a `Pod` running in the cluster
sees. The simplest way to do this is to run an interactive busybox `Pod`:
sees. The simplest way to do this is to run an interactive alpine `Pod`:
```none
kubectl run -it --rm --restart=Never busybox --image=busybox sh
kubectl run -it --rm --restart=Never alpine --image=alpine sh
/ #
```
{{< note >}}
@@ -219,7 +219,7 @@ own cluster.
You can also try this from a `Node` in the cluster:
{{< note >}}
10.0.0.10 is my DNS `Service`, yours might be different).
10.0.0.10 is my DNS `Service`, yours might be different.
{{< /note >}}
```shell
content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
+1 -1
View File
@@ -44,7 +44,7 @@ it to [support other log format](/docs/tasks/debug-application-cluster/monitor-n
## Enable/Disable in GCE cluster
Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
Node problem detector is [running as a cluster addon](/docs/setup/best-practices/cluster-large/#addon-resources) enabled by default in the
gce cluster.
You can enable/disable it by setting the environment variable
content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+8
View File
@@ -75,6 +75,14 @@ Prometheus provides a robust query language and a built-in dashboard for
querying and visualizing your data. Prometheus is also a supported
data source for [Grafana](https://prometheus.io/docs/visualization/grafana/).
### Sysdig
[Sysdig](http://sysdig.com) provides full spectrum container and platform intelligence, and is a
true container native solution. Sysdig pulls together data from system calls, Kubernetes events,
Prometheus metrics, statsD, JMX, and more into a single pane that gives you a comprehensive picture
of your environment. Sysdig also provides an API to query for providing robust and customizable
solutions. Sysdig is built on Open Source. [Sysdig and Sysdig Inspect](https://sysdig.com/opensource/inspect/) give you the
ability to freely perform troubleshooting, performance analyis and forensics.
### Google Cloud Monitoring
Google Cloud Monitoring is a hosted monitoring service you can use to
content/en/docs/tasks/debug-application-cluster/troubleshooting.md
+3 -1
View File
@@ -70,6 +70,7 @@ There are also many country specific/local language channels. Feel free to join
these channels for localized support and info:
- China: `#cn-users`, `#cn-events`
- Finland: `#fi-users`
- France: `#fr-users`, `#fr-events`
- Germany: `#de-users`, `#de-events`
- India: `#in-users`, `#in-events`
@@ -81,6 +82,7 @@ these channels for localized support and info:
- Poland: `#pl-users`
- Russia: `#ru-users`
- Spain: `#es-users`
- Sweden: `#se-users`
- Turkey: `#tr-users`, `#tr-events`
### Forum
@@ -90,7 +92,7 @@ The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes
### Bugs and Feature requests
If you have what looks like a bug, or you would like to make a feature request,
please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues).
Before you file an issue, please search existing issues to see if your issue is
already covered.
content/en/docs/tasks/federation/administer-federation/cluster.md
+2 -2
View File
@@ -20,7 +20,7 @@ federation api-server.
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic [working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
* You should also have a basic [working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general.
{{% /capture %}}
@@ -85,7 +85,7 @@ kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
## ClusterSelector Annotation
Starting in Kubernetes 1.7, there is alpha support for directing objects across the federated clusters with the annotation `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.
You can use a (deprecated) annotation for directing objects across the federated clusters: `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.
The annotation value must be JSON formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type ConfigMap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
content/en/docs/tasks/federation/administer-federation/configmap.md
+1 -1
View File
@@ -22,7 +22,7 @@ across all the clusters in federation.
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/daemonset.md
+2 -2
View File
@@ -21,8 +21,8 @@ across all the clusters in federation.
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/deployment.md
+1 -1
View File
@@ -27,7 +27,7 @@ Some features
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You should also have a basic
[working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Deployments](/docs/concepts/workloads/controllers/deployment/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/events.md
+2 -2
View File
@@ -26,8 +26,8 @@ this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general.
## View federation events
content/en/docs/tasks/federation/administer-federation/hpa.md
+2 -2
View File
@@ -25,8 +25,8 @@ needed most by manipulating the min and max limits of the HPA objects in the fed
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular.
The federated HPA is an alpha feature. The API is not enabled by default on the
content/en/docs/tasks/federation/administer-federation/ingress.md
+2 -2
View File
@@ -71,8 +71,8 @@ this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You must also have a basic
[working knowledge of Kubernetes](/docs/setup/) in
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general, and [Ingress](/docs/concepts/services-networking/ingress/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/job.md
+2 -2
View File
@@ -21,8 +21,8 @@ parallelism and completions exist across the registered clusters.
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/namespaces.md
+1 -1
View File
@@ -22,7 +22,7 @@ across all the clusters in federation.
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/replicaset.md
+2 -2
View File
@@ -21,8 +21,8 @@ replicas exist across the registered clusters.
{{% capture prerequisites %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) in particular.
{{% /capture %}}
content/en/docs/tasks/federation/administer-federation/secret.md
+2 -2
View File
@@ -31,8 +31,8 @@ this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Secrets](/docs/concepts/configuration/secret/) in particular.
## Creating a Federated Secret
content/en/docs/tasks/federation/federation-service-discovery.md
+2 -2
View File
@@ -62,8 +62,8 @@ this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
You are also expected to have a basic
[working knowledge of Kubernetes](/docs/setup/) in
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general, and [Services](/docs/concepts/services-networking/service/) in particular.
## Hybrid cloud capabilities
content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+1 -1
View File
@@ -536,7 +536,7 @@ as described in the
## Removing a cluster from a federation
To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/admin/kubefed_unjoin/)
To remove a cluster from a federation, run the [`kubefed unjoin`](/docs/reference/setup-tools/kubefed/kubefed_unjoin/)
command with the cluster name and the federation's
`--host-cluster-context`:
content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+71 -41
View File
@@ -143,48 +143,78 @@ is exposed:
my-app
39528$vdg7Jb
```
## Create a Pod that has access to the secret data through environment variables
Here is a configuration file you can use to create a Pod:
{{< codenew file="pods/inject/secret-envars-pod.yaml" >}}
1. Create the Pod:
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
```
1. Verify that your Pod is running:
```shell
kubectl get pod secret-envars-test-pod
```
Output:
```shell
NAME READY STATUS RESTARTS AGE
secret-envars-test-pod 1/1 Running 0 4m
```
1. Get a shell into the Container that is running in your Pod:
```shell
kubectl exec -it secret-envars-test-pod -- /bin/bash
```
1. In your shell, display the environment variables:
```shell
root@secret-envars-test-pod:/# printenv
```
The output includes your username and password:
```shell
...
SECRET_USERNAME=my-app
...
SECRET_PASSWORD=39528$vdg7Jb
```
## Define container environment variables using Secret data
### Define a container environment variable with data from a single Secret
* Define an environment variable as a key-value pair in a Secret:
```shell
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
```
* Assign the `backend-username` value defined in the Secret to the `SECRET_USERNAME` environment variable in the Pod specification.
{{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
* Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
```
* Now, the Pod’s output includes environment variable `SECRET_USERNAME=backend-admin`
### Define container environment variables with data from multiple Secrets
* As with the previous example, create the Secrets first.
```shell
kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
kubectl create secret generic db-user --from-literal=db-username='db-admin'
```
* Define the environment variables in the Pod specification.
{{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
* Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
```
* Now, the Pod’s output includes `BACKEND_USERNAME=backend-admin` and `DB_USERNAME=db-admin` environment variables.
## Configure all key-value pairs in a Secret as container environment variables
{{< note >}}
This functionality is available in Kubernetes v1.6 and later.
{{< /note >}}
* Create a Secret containing multiple key-value pairs
```shell
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
```
* Use envFrom to define all of the Secret’s data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
{{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
* Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
```
* Now, the Pod’s output includes `username=my-app` and `password=39528$vdg7Jb` environment variables.
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+10 -5
View File
@@ -199,13 +199,9 @@ The following information is available to containers through environment
variables and `downwardAPI` volumes:
* Information available via `fieldRef`:
* `spec.nodeName` - the node’s name
* `status.hostIP` - the node's IP
* `metadata.name` - the pod’s name
* `metadata.namespace` - the pod’s namespace
* `status.podIP` - the pod’s IP address
* `spec.serviceAccountName` - the pod’s service account name
* `metadata.uid` - the pod’s UID
* `metadata.uid` - the pod’s UID, available since v1.8.0-alpha.2
* `metadata.labels['<KEY>']` - the value of the pod’s label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
* `metadata.annotations['<KEY>']` - the value of the pod’s annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
* Information available via `resourceFieldRef`:
@@ -213,6 +209,8 @@ variables and `downwardAPI` volumes:
* A Container’s CPU request
* A Container’s memory limit
* A Container’s memory request
* A Container’s ephemeral-storage limit, available since v1.8.0-beta.0
* A Container’s ephemeral-storage request, available since v1.8.0-beta.0
In addition, the following information is available through
`downwardAPI` volume `fieldRef`:
@@ -220,6 +218,13 @@ In addition, the following information is available through
* `metadata.labels` - all of the pod’s labels, formatted as `label-key="escaped-label-value"` with one label per line
* `metadata.annotations` - all of the pod’s annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
The following information is available through environment variables:
* `status.podIP` - the pod’s IP address
* `spec.serviceAccountName` - the pod’s service account name, available since v1.4.0-alpha.3
* `spec.nodeName` - the node’s name, available since v1.4.0-alpha.3
* `status.hostIP` - the node's IP, available since v1.7.0-alpha.1
{{< note >}}
If CPU and memory limits are not specified for a Container, the
Downward API defaults to the node allocatable value for CPU and memory.
content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
+2 -2
View File
@@ -114,7 +114,7 @@ The job name and pod name are different.
```shell
# Replace "hello-4111706356" with the job name in your system
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items.metadata.name})
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[].metadata.name})
```
Show pod log:
@@ -145,7 +145,7 @@ As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and
information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications),
and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
{{< note >}}
All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
content/en/docs/tasks/job/parallel-processing-expansion.md
+35 -7
View File
@@ -42,6 +42,9 @@ Note that the label key `jobgroup` is not special to Kubernetes. You can pick yo
Next, expand the template into multiple files, one for each item to be processed.
```shell
# Download job-templ.yaml
curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml
# Expand files into a temporary directory
mkdir ./jobs
for i in apple banana cherry
@@ -54,6 +57,11 @@ Check if it worked:
```shell
ls jobs/
```
The output is similar to this:
```
job-apple.yaml
job-banana.yaml
job-cherry.yaml
@@ -67,19 +75,29 @@ Next, create all the jobs with one kubectl command:
```shell
kubectl create -f ./jobs
job "process-item-apple" created
job "process-item-banana" created
job "process-item-cherry" created
```
The output is similar to this:
```
job.batch/process-item-apple created
job.batch/process-item-banana created
job.batch/process-item-cherry created
```
Now, check on the jobs:
```shell
kubectl get jobs -l jobgroup=jobexample
NAME DESIRED SUCCESSFUL AGE
process-item-apple 1 1 31s
process-item-banana 1 1 31s
process-item-cherry 1 1 31s
```
The output is similar to this:
```
NAME COMPLETIONS DURATION AGE
process-item-apple 1/1 14s 20s
process-item-banana 1/1 12s 20s
process-item-cherry 1/1 12s 20s
```
Here we use the `-l` option to select all jobs that are part of this
@@ -90,6 +108,11 @@ We can check on the pods as well using the same label selector:
```shell
kubectl get pods -l jobgroup=jobexample
```
The output is similar to this:
```
NAME READY STATUS RESTARTS AGE
process-item-apple-kixwv 0/1 Completed 0 4m
process-item-banana-wrsf7 0/1 Completed 0 4m
@@ -104,6 +127,11 @@ for p in $(kubectl get pods -l jobgroup=jobexample -o name)
do
kubectl logs $p
done
```
The output is:
```
Processing item apple
Processing item banana
Processing item cherry
content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
+1
View File
@@ -3,6 +3,7 @@ reviewers:
- janetkuo
title: Perform a Rollback on a DaemonSet
content_template: templates/task
weight: 20
---
{{% capture overview %}}
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+3 -2
View File
@@ -3,6 +3,7 @@ reviewers:
- janetkuo
title: Perform a Rolling Update on a DaemonSet
content_template: templates/task
weight: 10
---
{{% capture overview %}}
@@ -94,7 +95,7 @@ update. This can be done with several different `kubectl` commands.
#### Declarative commands
If you update DaemonSets using
[configuration files](/docs/concepts/overview/object-management-kubectl/declarative-config/),
[configuration files](/docs/tasks/manage-kubernetes-objects/declarative-config/),
use `kubectl apply`:
```shell
@@ -104,7 +105,7 @@ kubectl apply -f ds-v2.yaml
#### Imperative commands
If you update DaemonSets using
[imperative commands](/docs/concepts/overview/object-management-kubectl/imperative-command/),
[imperative commands](/docs/tasks/manage-kubernetes-objects/imperative-command/),
use `kubectl edit` or `kubectl patch`:
```shell
content/en/docs/tasks/manage-gpus/scheduling-gpus.md
+5 -1
View File
@@ -174,7 +174,11 @@ For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenComput
Example result:
$ kubectl describe node cluster-node-23
```console
kubectl describe node cluster-node-23
```
The output is similar to:
Name: cluster-node-23
Roles: <none>
Labels: beta.amd.com/gpu.cu-count.64=1
content/en/docs/tasks/manage-kubernetes-objects/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Manage Kubernetes Objects"
weight: 25
---
content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
+1002
View File
File diff suppressed because it is too large Load Diff
content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
+171
View File
@@ -0,0 +1,171 @@
---
title: Managing Kubernetes Objects Using Imperative Commands
content_template: templates/task
weight: 30
---
{{% capture overview %}}
Kubernetes objects can quickly be created, updated, and deleted directly using
imperative commands built into the `kubectl` command-line tool. This document
explains how those commands are organized and how to use them to manage live objects.
{{% /capture %}}
{{% capture prerequisites %}}
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Trade-offs
The `kubectl` tool supports three kinds of object management:
* Imperative commands
* Imperative object configuration
* Declarative object configuration
See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
for a discussion of the advantages and disadvantage of each kind of object management.
## How to create objects
The `kubectl` tool supports verb-driven commands for creating some of the most common
object types. The commands are named to be recognizable to users unfamiliar with
the Kubernetes object types.
- `run`: Create a new Deployment object to run Containers in one or more Pods.
- `expose`: Create a new Service object to load balance traffic across Pods.
- `autoscale`: Create a new Autoscaler object to automatically horizontally scale a controller, such as a Deployment.
The `kubectl` tool also supports creation commands driven by object type.
These commands support more object types and are more explicit about
their intent, but require users to know the type of objects they intend
to create.
- `create <objecttype> [<subtype>] <instancename>`
Some objects types have subtypes that you can specify in the `create` command.
For example, the Service object has several subtypes including ClusterIP,
LoadBalancer, and NodePort. Here's an example that creates a Service with
subtype NodePort:
```shell
kubectl create service nodeport <myservicename>
```
In the preceding example, the `create service nodeport` command is called
a subcommand of the `create service` command.
You can use the `-h` flag to find the arguments and flags supported by
a subcommand:
```shell
kubectl create service nodeport -h
```
## How to update objects
The `kubectl` command supports verb-driven commands for some common update operations.
These commands are named to enable users unfamiliar with Kubernetes
objects to perform updates without knowing the specific fields
that must be set:
- `scale`: Horizontally scale a controller to add or remove Pods by updating the replica count of the controller.
- `annotate`: Add or remove an annotation from an object.
- `label`: Add or remove a label from an object.
The `kubectl` command also supports update commands driven by an aspect of the object.
Setting this aspect may set different fields for different object types:
- `set` `<field>`: Set an aspect of an object.
{{< note >}}
In Kubernetes version 1.5, not every verb-driven command has an associated aspect-driven command.
{{< /note >}}
The `kubectl` tool supports these additional ways to update a live object directly,
however they require a better understanding of the Kubernetes object schema.
- `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor.
- `patch`: Directly modify specific fields of a live object by using a patch string.
For more details on patch strings, see the patch section in
[API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#patch-operations).
## How to delete objects
You can use the `delete` command to delete an object from a cluster:
- `delete <type>/<name>`
{{< note >}}
You can use `kubectl delete` for both imperative commands and imperative object
configuration. The difference is in the arguments passed to the command. To use
`kubectl delete` as an imperative command, pass the object to be deleted as
an argument. Here's an example that passes a Deployment object named nginx:
{{< /note >}}
```shell
kubectl delete deployment/nginx
```
## How to view an object
{{< comment >}}
TODO(pwittrock): Uncomment this when implemented.
You can use `kubectl view` to print specific fields of an object.
- `view`: Prints the value of a specific field of an object.
{{< /comment >}}
There are several commands for printing information about an object:
- `get`: Prints basic information about matching objects. Use `get -h` to see a list of options.
- `describe`: Prints aggregated detailed information about matching objects.
- `logs`: Prints the stdout and stderr for a container running in a Pod.
## Using `set` commands to modify objects before creation
There are some object fields that don't have a flag you can use
in a `create` command. In some of those cases, you can use a combination of
`set` and `create` to specify a value for the field before object
creation. This is done by piping the output of the `create` command to the
`set` command, and then back to the `create` command. Here's an example:
```sh
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
```
1. The `kubectl create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
1. The `kubectl set selector --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
1. The `kubectl create -f -` command creates the object using the configuration provided via stdin.
## Using `--edit` to modify objects before creation
You can use `kubectl create --edit` to make arbitrary changes to an object
before it is created. Here's an example:
```sh
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run > /tmp/srv.yaml
kubectl create --edit -f /tmp/srv.yaml
```
1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object.
{{% /capture %}}
{{% capture whatsnext %}}
* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
+154
View File
@@ -0,0 +1,154 @@
---
title: Imperative Management of Kubernetes Objects Using Configuration Files
content_template: templates/task
weight: 40
---
{{% capture overview %}}
Kubernetes objects can be created, updated, and deleted by using the `kubectl`
command-line tool along with an object configuration file written in YAML or JSON.
This document explains how to define and manage objects using configuration files.
{{% /capture %}}
{{% capture prerequisites %}}
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Trade-offs
The `kubectl` tool supports three kinds of object management:
* Imperative commands
* Imperative object configuration
* Declarative object configuration
See [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)
for a discussion of the advantages and disadvantage of each kind of object management.
## How to create objects
You can use `kubectl create -f` to create an object from a configuration file.
Refer to the [kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
for details.
* `kubectl create -f <filename|url>`
## How to update objects
{{< warning >}}
Updating objects with the `replace` command drops all
parts of the spec not specified in the configuration file. This
should not be used with objects whose specs are partially managed
by the cluster, such as Services of type `LoadBalancer`, where
the `externalIPs` field is managed independently from the configuration
file. Independently managed fields must be copied to the configuration
file to prevent `replace` from dropping them.
{{< /warning >}}
You can use `kubectl replace -f` to update a live object according to a
configuration file.
* `kubectl replace -f <filename|url>`
## How to delete objects
You can use `kubectl delete -f` to delete an object that is described in a
configuration file.
* `kubectl delete -f <filename|url>`
## How to view an object
You can use `kubectl get -f` to view information about an object that is
described in a configuration file.
* `kubectl get -f <filename|url> -o yaml`
The `-o yaml` flag specifies that the full object configuration is printed.
Use `kubectl get -h` to see a list of options.
## Limitations
The `create`, `replace`, and `delete` commands work well when each object's
configuration is fully defined and recorded in its configuration
file. However when a live object is updated, and the updates are not merged
into its configuration file, the updates will be lost the next time a `replace`
is executed. This can happen if a controller, such as
a HorizontalPodAutoscaler, makes updates directly to a live object. Here's
an example:
1. You create an object from a configuration file.
1. Another source updates the object by changing some field.
1. You replace the object from the configuration file. Changes made by
the other source in step 2 are lost.
If you need to support multiple writers to the same object, you can use
`kubectl apply` to manage the object.
## Creating and editing an object from a URL without saving the configuration
Suppose you have the URL of an object configuration file. You can use
`kubectl create --edit` to make changes to the configuration before the
object is created. This is particularly useful for tutorials and tasks
that point to a configuration file that could be modified by the reader.
```shell
kubectl create -f <url> --edit
```
## Migrating from imperative commands to imperative object configuration
Migrating from imperative commands to imperative object configuration involves
several manual steps.
1. Export the live object to a local object configuration file:
```shell
kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
```
1. Manually remove the status field from the object configuration file.
1. For subsequent object management, use `replace` exclusively.
```shell
kubectl replace -f <kind>_<name>.yaml
```
## Defining controller selectors and PodTemplate labels
{{< warning >}}
Updating selectors on controllers is strongly discouraged.
{{< /warning >}}
The recommended approach is to define a single, immutable PodTemplate label
used only by the controller selector with no other semantic meaning.
Example label:
```yaml
selector:
matchLabels:
controller-selector: "extensions/v1beta1/deployment/nginx"
template:
metadata:
labels:
controller-selector: "extensions/v1beta1/deployment/nginx"
```
{{% /capture %}}
{{% capture whatsnext %}}
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+830
View File
@@ -0,0 +1,830 @@
---
title: Declarative Management of Kubernetes Objects Using Kustomize
content_template: templates/task
weight: 20
---
{{% capture overview %}}
[Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool
to customize Kubernetes objects
through a [kustomization file](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/kustomization.yaml).
Since 1.14, Kubectl also
supports the management of Kubernetes objects using a kustomization file.
To view Resources found in a directory containing a kustomization file, run the following command:
```shell
kubectl kustomize <kustomization_directory>
```
To apply those Resources, run `kubectl apply` with `--kustomize` or `-k` flag:
```shell
kubectl apply -k <kustomization_directory>
```
{{% /capture %}}
{{% capture prerequisites %}}
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{% /capture %}}
{{% capture steps %}}
## Overview of Kustomize
Kustomize is a tool for customizing Kubernetes configurations. It has the following features to manage application configuration files:
* generating resources from other sources
* setting cross-cutting fields for resources
* composing and customizing collections of resources
### Generating Resources
ConfigMap and Secret hold config or sensitive data that are used by other Kubernetes objects, such as Pods. The source
of truth of ConfigMap or Secret are usually from somewhere else, such as a `.properties` file or a ssh key file.
Kustomize has `secretGenerator` and `configMapGenerator`, which generate Secret and ConfigMap from files or literals.
#### configMapGenerator
To generate a ConfigMap from a file, add an entry to `files` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a file content.
```shell
# Create a application.properties file
cat <<EOF >application.properties
FOO=Bar
EOF
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-1
files:
- application.properties
EOF
```
The generated ConfigMap can be checked by the following command:
```shell
kubectl kustomize ./
```
The generated ConfigMap is:
```yaml
apiVersion: v1
data:
application.properties: |
FOO=Bar
kind: ConfigMap
metadata:
name: example-configmap-1-8mbdf7882g
```
ConfigMap can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair.
```shell
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-2
literals:
- FOO=Bar
EOF
```
The generated ConfigMap can be checked by the following command:
```shell
kubectl kustomize ./
```
The generated ConfigMap is
```yaml
apiVersion: v1
data:
FOO: Bar
kind: ConfigMap
metadata:
name: example-configmap-2-g2hdhfc6tk
```
#### secretGenerator
You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to `files` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a file.
```shell
# Create a password.txt file
cat <<EOF >./password.txt
username=admin
password=secret
EOF
cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-1
files:
- password.txt
EOF
```
The generated Secret is as follows:
```yaml
apiVersion: v1
data:
password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg==
kind: Secret
metadata:
name: example-secret-1-t2kt65hgtb
type: Opaque
```
To generate a Secret from a literal key-value pair, add an entry to `literals` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a key-value pair.
```shell
cat <<EOF >./kustomization.yaml
secretGenerator:
- name: example-secret-2
literals:
- username=admin
- password=secert
EOF
```
The generated Secret is as follows:
```yaml
apiVersion: v1
data:
password: c2VjZXJ0
username: YWRtaW4=
kind: Secret
metadata:
name: example-secret-2-t52t6g96d8
type: Opaque
```
#### generatorOptions
The generated ConfigMaps and Secrets have a suffix appended by hashing the contents. This ensures that a new ConfigMap or Secret is generated when the content is changed. To disable the behavior of appending a suffix, one can use `generatorOptions`. Besides that, it is also possible to specify cross-cutting options for generated ConfigMaps and Secrets.
```shell
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-configmap-3
literals:
- FOO=Bar
generatorOptions:
disableNameSuffixHash: true
labels:
type: generated
annotations:
note: generated
EOF
```
Run`kubectl kustomize ./` to view the generated ConfigMap:
```yaml
apiVersion: v1
data:
FOO: Bar
kind: ConfigMap
metadata:
annotations:
note: generated
labels:
type: generated
name: example-configmap-3
```
### Setting cross-cutting fields
It is quite common to set cross-cutting fields for all Kubernetes resources in a project.
Some use cases for setting cross-cutting fields:
* setting the same namespace for all Resource
* adding the same name prefix or suffix
* adding the same set of labels
* adding the same set of annotations
Here is an example:
```shell
# Create a deployment.yaml
cat <<EOF >./deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
EOF
cat <<EOF >./kustomization.yaml
namespace: my-namespace
namePrefix: dev-
nameSuffix: "-001"
commonLabels:
app: bingo
commonAnnotations:
oncallPager: 800-555-1212
resources:
- deployment.yaml
EOF
```
Run `kubectl kustomize ./` to view those fields are all set in the Deployment Resource:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
oncallPager: 800-555-1212
labels:
app: bingo
name: dev-nginx-deployment-001
namespace: my-namespace
spec:
selector:
matchLabels:
app: bingo
template:
metadata:
annotations:
oncallPager: 800-555-1212
labels:
app: bingo
spec:
containers:
- image: nginx
name: nginx
```
### Composing and Customizing Resources
It is common to compose a set of Resources in a project and manage them inside
the same file or directory.
Kustomize offers composing Resources from different files and applying patches or other customization to them.
#### Composing
Kustomize supports composition of different resources. The `resources` field, in the `kustomization.yaml` file, defines the list of resources to include in a configuration. Set the path to a resource's configuration file in the `resources` list.
Here is an example for an nginx application with a Deployment and a Service.
```shell
# Create a deployment.yaml file
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF
# Create a service.yaml file
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
EOF
# Create a kustomization.yaml composing them
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF
```
The Resources from `kubectl kustomize ./` contains both the Deployment and the Service objects.
#### Customizing
On top of Resources, one can apply different customizations by applying patches. Kustomize supports different patching
mechanisms through `patchesStrategicMerge` and `patchesJson6902`. `patchesStrategicMerge` is a list of file paths. Each file should be resolved to a [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). The names inside the patches must match Resource names that are already loaded. Small patches that do one thing are recommended. For example, create one patch for increasing the deployment replica number and another patch for setting the memory limit.
```shell
# Create a deployment.yaml file
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF
# Create a patch increase_replicas.yaml
cat <<EOF > increase_replicas.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 3
EOF
# Create another patch set_memory.yaml
cat <<EOF > set_memory.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
template:
spec:
containers:
- name: my-nginx
resources:
limits:
memory: 512Mi
EOF
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
patchesStrategicMerge:
- increase_replicas.yaml
- set_memory.yaml
EOF
```
Run `kubectl kustomize ./` to view the Deployment:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 3
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- image: nginx
limits:
memory: 512Mi
name: my-nginx
ports:
- containerPort: 80
```
Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources,
Kustomize offers applying [JSON patch](https://tools.ietf.org/html/rfc6902) through `patchesJson6902`.
To find the correct Resource for a Json patch, the group, version, kind and name of that Resource need to be
specified in `kustomization.yaml`. For example, increasing the replica number of a Deployment object can also be done
through `patchesJson6902`.
```shell
# Create a deployment.yaml file
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF
# Create a json patch
cat <<EOF > patch.yaml
- op: replace
path: /spec/replicas
value: 3
EOF
# Create a kustomization.yaml
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
patchesJson6902:
- target:
group: apps
version: v1
kind: Deployment
name: my-nginx
path: patch.yaml
EOF
```
Run `kubectl kustomize ./` to see the `replicas` field is updated:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 3
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- image: nginx
name: my-nginx
ports:
- containerPort: 80
```
In addition to patches, Kustomize also offers customizing container images or injecting field values from other objects into containers
without creating patches. For example, you can change the image used inside containers by specifying the new image in `images` field in `kustomization.yaml`.
```shell
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF
cat <<EOF >./kustomization.yaml
resources:
- deployment.yaml
images:
- name: nginx
newName: my.image.registry/nginx
newTag: 1.4.0
EOF
```
Run `kubectl kustomize ./` to see that the image being used is updated:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 2
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- image: my.image.registry/nginx:1.4.0
name: my-nginx
ports:
- containerPort: 80
```
Sometimes, the application running in a Pod may need to use configuration values from other objects. For example,
a Pod from a Deployment object need to read the corresponding Service name from Env or as a command argument.
Since the Service name may change as `namePrefix` or `nameSuffix` is added in the `kustomization.yaml` file. It is
not recommended to hard code the Service name in the command argument. For this usage, Kustomize can inject the Service name into containers through `vars`.
```shell
# Create a deployment.yaml file
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
command: ["start", "--host", "\$(MY_SERVICE_NAME)"]
EOF
# Create a service.yaml file
cat <<EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
EOF
cat <<EOF >./kustomization.yaml
namePrefix: dev-
nameSuffix: "-001"
resources:
- deployment.yaml
- service.yaml
vars:
- name: MY_SERVICE_NAME
objref:
kind: Service
name: my-nginx
apiVersion: v1
EOF
```
Run `kubectl kustomize ./` to see that the Service name injected into containers is `dev-my-nginx-001`:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dev-my-nginx-001
spec:
replicas: 2
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- command:
- start
- --host
- dev-my-nginx-001
image: nginx
name: my-nginx
```
## Bases and Overlays
Kustomize has the concepts of **bases** and **overlays**. A **base** is a directory with a `kustomization.yaml`, which contains a
set of resources and associated customization. A base could be either a local directory or a directory from a remote repo,
as long as a `kustomization.yaml` is present inside. An **overlay** is a directory with a `kustomization.yaml` that refers to other
kustomization directories as its `bases`. A **base** has no knowledge of an overlay and can be used in multiple overlays.
An overlay may have multiple bases and it composes all resources
from bases and may also have customization on top of them.
Here is an example of a base:
```shell
# Create a directory to hold the base
mkdir base
# Create a base/deployment.yaml
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
EOF
# Create a base/service.yaml file
cat <<EOF > base/service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
EOF
# Create a base/kustomization.yaml
cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
```
This base can be used in multiple overlays. You can add different `namePrefix` or other cross-cutting fields
in different overlays. Here are two overlays using the same base.
```shell
mkdir dev
cat <<EOF > dev/kustomization.yaml
bases:
- ../base
namePrefix: dev-
EOF
mkdir prod
cat <<EOF > prod/kustomization.yaml
bases:
- ../base
namePrefix: prod-
EOF
```
## How to apply/view/delete objects using Kustomize
Use `--kustomize` or `-k` in `kubectl` commands to recognize Resources managed by `kustomization.yaml`.
Note that `-k` should point to a kustomization directory, such as
```shell
kubectl apply -k <kustomization directory>/
```
Given the following `kustomization.yaml`,
```shell
# Create a deployment.yaml file
cat <<EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
EOF
# Create a kustomization.yaml
cat <<EOF >./kustomization.yaml
namePrefix: dev-
commonLabels:
app: my-nginx
resources:
- deployment.yaml
EOF
```
Run the following command to apply the Deployment object `dev-my-nginx`:
```shell
> kubectl apply -k ./
deployment.apps/dev-my-nginx created
```
Run one of the following commands to view the Deployment object `dev-my-nginx`:
```shell
kubectl get -k ./
```
```shell
kubectl describe -k ./
```
Run the following command to delete the Deployment object `dev-my-nginx`:
```shell
> kubectl delete -k ./
deployment.apps "dev-my-nginx" deleted
```
## Kustomize Feature List
| Field | Type | Explanation |
|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| namespace | string | add namespace to all resources |
| namePrefix | string | value of this field is prepended to the names of all resources |
| nameSuffix | string | value of this field is appended to the names of all resources |
| commonlabels | map[string]string | labels to add to all resources and selectors |
| commonAnnotations | map[string]string | annotations to add to all resources |
| resources | []string | each entry in this list must resolve to an existing resource configuration file |
| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L195) | Each entry in this list generates a ConfigMap |
| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L201) | Each entry in this list generates a Secret |
| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L239) | Modify behaviors of all ConfigMap and Secret generatos |
| bases | []string | Each entry in this list should resolve to a directory containing a kustomization.yaml file |
| patchesStrategicMerge | []string | Each entry in this list should resolve a strategic merge patch of a Kubernetes object |
| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/patch/json6902.go#L23) | Each entry in this list should resolve to a Kubernetes object and a Json Patch |
| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/var.go#L31) | Each entry is to capture text from one resource's field |
| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/image/image.go#L23) | Each entry is to modify the name, tags and/or digest for one image without creating patches |
| configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) |
| crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types |
{{% /capture %}}
{{% capture whatsnext %}}
* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/en/docs/tasks/run-application/configure-pdb.md
+19 -23
View File
@@ -79,6 +79,22 @@ due to a voluntary disruption.
- Concern: Job needs to complete in case of voluntary disruption.
- Possible solution: Do not create a PDB. The Job controller will create a replacement pod.
### Rounding logic when specifying percentages
Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage.
- When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
Pods must always be available, even during a disruption.
- When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
total Pods. For instance, if you set `minUnavailable` to `"50%"`, then only 50% of the Pods can be unavailable during a
disruption.
When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. You can examine the
[code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
that controls this behavior.
## Specifying a PodDisruptionBudget
A `PodDisruptionBudget` has three fields:
@@ -137,31 +153,11 @@ You can find examples of pod disruption budgets defined below. They match pods w
Example PDB Using minAvailable:
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeper
```
{{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
Example PDB Using maxUnavailable (Kubernetes 1.7 or higher):
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: zookeeper
```
{{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
specifications have the exact same meaning. The use of `maxUnavailable` is recommended as it
@@ -213,7 +209,7 @@ metadata:
creationTimestamp: 2017-08-28T02:38:26Z
generation: 1
name: zk-pdb
...
…
status:
currentHealthy: 3
desiredHealthy: 3
content/en/docs/tasks/run-application/delete-stateful-set.md
+1 -1
View File
@@ -12,7 +12,7 @@ weight: 60
{{% capture overview %}}
This task shows you how to delete a StatefulSet.
This task shows you how to delete a {{< glossary_tooltip term_id="StatefulSet" >}}.
{{% /capture %}}
content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+2 -2
View File
@@ -10,7 +10,7 @@ weight: 70
---
{{% capture overview %}}
This page shows how to delete Pods which are part of a stateful set, and explains the considerations to keep in mind when doing so.
This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -24,7 +24,7 @@ This page shows how to delete Pods which are part of a stateful set, and explain
## StatefulSet considerations
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The [StatefulSet controller](/docs/concepts/workloads/controllers/statefulset/) is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
Manual force deletion should be undertaken with caution, as it has the potential to violate the at most one semantics inherent to StatefulSet. StatefulSets may be used to run distributed and clustered applications which have a need for a stable network identity and stable storage. These applications often have configuration which relies on an ensemble of a fixed number of members with fixed identities. Having multiple members with the same identity can be disastrous and may lead to data loss (e.g. split brain scenario in quorum-based systems).
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+6 -6
View File
@@ -25,8 +25,8 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
@@ -75,7 +75,7 @@ deployment.apps/php-apache created
## Create Horizontal Pod Autoscaler
Now that the server is running, we will create the autoscaler using
[kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_autoscale.md).
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
controlled by the php-apache deployment we created in the first step of these instructions.
Roughly speaking, HPA will increase and decrease the number of replicas
@@ -271,7 +271,7 @@ object:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
@@ -316,7 +316,7 @@ spec:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
@@ -339,7 +339,7 @@ status:
metric:
name: requests-per-second
describedObject:
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
current:
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+3 -3
View File
@@ -71,7 +71,7 @@ or the custom metrics API (for all other metrics).
The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
`custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by
metrics-server, which needs to be launched separately. See
[metrics-server](/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)
[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
{{< note >}}
@@ -164,7 +164,7 @@ the current value.
Finally, just before HPA scales the target, the scale recommendation is recorded. The
controller considers all recommendations within a configurable window choosing the
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes.
highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
fluctuating metric values.
@@ -219,7 +219,7 @@ the global HPA settings exposed as flags for the `kube-controller-manager` compo
Starting from v1.12, a new algorithmic update removes the need for the
upscale delay.
- `--horizontal-pod-autoscaler-downscale-delay`: The value for this option is a
- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
duration that specifies how long the autoscaler has to wait before another
downscale operation can be performed after the current one has completed.
The default value is 5 minutes (`5m0s`).
content/en/docs/tasks/run-application/rolling-update-replication-controller.md
+31 -57
View File
@@ -37,8 +37,12 @@ A rolling update works by:
Rolling updates are initiated with the `kubectl rolling-update` command:
kubectl rolling-update NAME \
([NEW_NAME] --image=IMAGE | -f FILE)
```shell
kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
# or read the configuration from a file
kubectl rolling-update NAME -f FILE
```
{{% /capture %}}
@@ -50,7 +54,9 @@ Rolling updates are initiated with the `kubectl rolling-update` command:
To initiate a rolling update using a configuration file, pass the new file to
`kubectl rolling-update`:
kubectl rolling-update NAME -f FILE
```shell
kubectl rolling-update NAME -f FILE
```
The configuration file must:
@@ -65,25 +71,29 @@ Replication controller configuration files are described in
### Examples
// Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
kubectl rolling-update frontend-v1 -f frontend-v2.json
```shell
# Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
kubectl rolling-update frontend-v1 -f frontend-v2.json
// Update pods of frontend-v1 using JSON data passed into stdin.
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
# Update pods of frontend-v1 using JSON data passed into stdin.
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
```
## Updating the container image
To update only the container image, pass a new image name and tag with the
`--image` flag and (optionally) a new controller name:
kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
```shell
kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
```
The `--image` flag is only supported for single-container pods. Specifying
`--image` with multi-container pods returns an error.
If no `NEW_NAME` is specified, a new replication controller is created with
a temporary name. Once the rollout is complete, the old controller is deleted,
and the new controller is updated to use the original name.
If you didn't specify a new name, this creates a new replication controller
with a temporary name. Once the rollout is complete, the old controller is
deleted, and the new controller is updated to use the original name.
The update will fail if `IMAGE:TAG` is identical to the
current value. For this reason, we recommend the use of versioned tags as
@@ -94,11 +104,13 @@ Moreover, the use of `:latest` is not recommended, see
### Examples
// Update the pods of frontend-v1 to frontend-v2
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
```shell
# Update the pods of frontend-v1 to frontend-v2
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
// Update the pods of frontend, keeping the replication controller name
kubectl rolling-update frontend --image=image:v2
# Update the pods of frontend, keeping the replication controller name
kubectl rolling-update frontend --image=image:v2
```
## Required and optional fields
@@ -143,24 +155,7 @@ from the [`kubectl` reference](/docs/reference/generated/kubectl/kubectl-command
Let's say you were running version 1.7.9 of nginx:
```yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 5
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
{{< codenew file="controllers/replication-nginx-1.7.9.yaml" >}}
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
@@ -218,34 +213,13 @@ This is one example where the immutability of containers is a huge asset.
If you need to update more than just the image (e.g., command arguments, environment variables), you can create a new replication controller, with a new name and distinguishing label value, such as:
```yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx-v4
spec:
replicas: 5
selector:
app: nginx
deployment: v4
template:
metadata:
labels:
app: nginx
deployment: v4
spec:
containers:
- name: nginx
image: nginx:1.9.2
args: ["nginx", "-T"]
ports:
- containerPort: 80
```
{{< codenew file="controllers/replication-nginx-1.9.2.yaml" >}}
and roll it out:
```shell
kubectl rolling-update my-nginx -f ./nginx-rc.yaml
# Assuming you named the file "my-nginx.yaml"
kubectl rolling-update my-nginx -f ./my-nginx.yaml
```
```
Created my-nginx-v4
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+8 -8
View File
@@ -59,12 +59,12 @@ and a StatefulSet.
Create the ConfigMap from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
```
{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
This ConfigMap provides `my.cnf` overrides that let you independently control
configuration on the MySQL master and slaves.
In this case, you want the master to be able to serve replication logs to slaves
@@ -79,12 +79,12 @@ based on information provided by the StatefulSet controller.
Create the Services from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-services.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
```
{{< codenew file="application/mysql/mysql-services.yaml" >}}
The Headless Service provides a home for the DNS entries that the StatefulSet
controller creates for each Pod that's part of the set.
Because the Headless Service is named `mysql`, the Pods are accessible by
@@ -105,12 +105,12 @@ writes.
Finally, create the StatefulSet from the following YAML configuration file:
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
```
{{< codenew file="application/mysql/mysql-statefulset.yaml" >}}
You can watch the startup progress by running:
```shell
@@ -141,8 +141,8 @@ ordinal index.
It waits until each Pod reports being Ready before starting the next one.
In addition, the controller assigns each Pod a unique, stable name of the form
`<statefulset-name>-<ordinal-index>`.
In this case, that results in Pods named `mysql-0`, `mysql-1`, and `mysql-2`.
`<statefulset-name>-<ordinal-index>`, which results in Pods named `mysql-0`,
`mysql-1`, and `mysql-2`.
The Pod template in the above StatefulSet manifest takes advantage of these
properties to perform orderly startup of MySQL replication.
content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+4 -6
View File
@@ -330,11 +330,9 @@ and
{{% capture whatsnext %}}
* [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/imperative-config/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/declarative-config/)
* [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
{{% /capture %}}
content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+10 -4
View File
@@ -8,7 +8,11 @@ content_template: templates/task
{{% capture overview %}}
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
tool to easily install or uninstall Service Catalog on your Kubernetes cluster, linking it to
Google Cloud projects.
Service Catalog itself can work with any kind of managed service, not just Google Cloud.
{{% /capture %}}
@@ -29,13 +33,15 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
{{% capture steps %}}
## Install `sc` in your local environment
Install the `sc` CLI tool using the `go get` command:
The installer runs on your local computer as a CLI tool named `sc`.
```Go
Install using `go get`:
```shell
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
```
After running the above command, `sc` should be installed in your `GOPATH/bin` directory.
`sc` should now be installed in your `GOPATH/bin` directory.
## Install Service Catalog in your Kubernetes cluster
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+3 -5
View File
@@ -69,7 +69,7 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
"hosts": [
"my-svc.my-namespace.svc.cluster.local",
"my-pod.my-namespace.pod.cluster.local",
"172.168.0.24",
"192.0.2.24",
"10.0.34.2"
],
"CN": "my-pod.my-namespace.pod.cluster.local",
@@ -81,7 +81,7 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
EOF
```
Where `172.168.0.24` is the service's cluster IP,
Where `192.0.2.24` is the service's cluster IP,
`my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
`10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
is the pod's DNS name. You should see the following output:
@@ -110,8 +110,6 @@ kind: CertificateSigningRequest
metadata:
name: my-svc.my-namespace
spec:
groups:
- system:authenticated
request: $(cat server.csr | base64 | tr -d '\n')
usages:
- digital signature
@@ -147,7 +145,7 @@ Subject:
Serial Number:
Subject Alternative Names:
DNS Names: my-svc.my-namespace.svc.cluster.local
IP Addresses: 172.168.0.24
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
```
content/en/docs/tasks/tools/install-kubectl.md
+142 -122
View File
@@ -12,21 +12,51 @@ card:
---
{{% capture overview %}}
Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps.
The Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For a complete list of kubectl operations, see [Overview of kubectl](/docs/reference/kubectl/overview/).
{{% /capture %}}
{{% capture prerequisites %}}
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
{{% /capture %}}
{{% capture steps %}}
## Install kubectl
## Install kubectl on Linux
Here are a few methods to install kubectl.
### Install kubectl binary with curl on Linux
## Install kubectl binary using native package management
1. Download the latest release with the command:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on Linux, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
2. Make the kubectl binary executable.
```
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
### Install using native package management
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
@@ -50,9 +80,9 @@ yum install -y kubectl
{{< /tabs >}}
## Install with snap on Ubuntu
### Install with snap
If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
1. Switch to the snap user and run the installation command:
@@ -60,13 +90,48 @@ If you are on Ubuntu or one of other Linux distributions that support [snap](htt
sudo snap install kubectl --classic
```
2. Test to ensure the version you installed is sufficiently up-to-date:
2. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
## Install with Homebrew on macOS
## Install kubectl on macOS
### Install kubectl binary with curl on macOS
1. Download the latest release:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on macOS, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
2. Make the kubectl binary executable.
```
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
### Install with Homebrew on macOS
If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
@@ -76,13 +141,13 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
brew install kubernetes-cli
```
2. Test to ensure the version you installed is sufficiently up-to-date:
2. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
## Install with Macports on macOS
### Install with Macports on macOS
If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
@@ -93,13 +158,38 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
sudo port install kubectl
```
2. Test to ensure the version you installed is sufficiently up-to-date:
2. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
## Install with Powershell from PSGallery
## Install kubectl on Windows
### Install kubectl binary with curl on Windows
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
Or if you have `curl` installed, use this command:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
2. Add the binary in to your PATH.
3. Test to ensure the version of `kubectl` is the same as downloaded:
```
kubectl version
```
{{< note >}}
[Docker for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
If you have installed Docker before, you may need to place your PATH entry before the one added by Docker installer or remove the Docker's `kubectl`.
{{< /note >}}
### Install with Powershell from PSGallery
If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
@@ -114,7 +204,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
The installer creates `$HOME/.kube` and instructs it to create a config file
2. Test to ensure the version you installed is sufficiently up-to-date:
2. Test to ensure the version you installed is up-to-date:
```
kubectl version
@@ -122,9 +212,9 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
{{< note >}}Updating the installation is performed by rerunning the two commands listed in step 1.{{< /note >}}
## Install on Windows using Chocolatey or scoop
### Install on Windows using Chocolatey or Scoop
To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [scoop](https://scoop.sh) command-line installer.
To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer.
{{< tabs name="kubectl_win_install" >}}
{{% tab name="choco" %}}
@@ -137,7 +227,7 @@ To install kubectl on Windows you can use either [Chocolatey](https://chocolatey
{{% /tab %}}
{{< /tabs >}}
2. Test to ensure the version you installed is sufficiently up-to-date:
2. Test to ensure the version you installed is up-to-date:
```
kubectl version
@@ -179,93 +269,16 @@ You can install kubectl as part of the Google Cloud SDK.
gcloud components install kubectl
```
3. Test to ensure the version you installed is sufficiently up-to-date:
3. Test to ensure the version you installed is up-to-date:
```
kubectl version
```
## Install kubectl binary using curl
## Verifying kubectl configuration
{{< tabs name="kubectl_install_curl" >}}
{{% tab name="macOS" %}}
1. Download the latest release:
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using `kube-up.sh` or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`.
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on macOS, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
2. Make the kubectl binary executable.
```
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
{{% /tab %}}
{{% tab name="Linux" %}}
1. Download the latest release with the command:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on Linux, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
2. Make the kubectl binary executable.
```
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
{{% /tab %}}
{{% tab name="Windows" %}}
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
Or if you have `curl` installed, use this command:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
2. Add the binary in to your PATH.
{{% /tab %}}
{{< /tabs >}}
## Configure kubectl
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using kube-up.sh or successfully deploy a Minikube cluster. See the [getting started guides](/docs/setup/) for more about creating clusters. If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
By default, kubectl configuration is located at `~/.kube/config`.
## Check the kubectl configuration
Check that kubectl is properly configured by getting the cluster state:
```shell
@@ -273,13 +286,13 @@ kubectl cluster-info
```
If you see a URL response, kubectl is correctly configured to access your cluster.
If you see a message similar to the following, kubectl is not correctly configured or not able to connect to a Kubernetes cluster.
If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster.
```shell
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like Minikube to be installed first and then re-run the commands stated above.
If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
@@ -287,9 +300,11 @@ If kubectl cluster-info returns the url response but you can't access your clust
kubectl cluster-info dump
```
## Enabling shell autocompletion
## Optional kubectl configurations
kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing!
### Enabling shell autocompletion
kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing.
Below are the procedures to set up autocompletion for Bash (including the difference between Linux and macOS) and Zsh.
@@ -344,40 +359,42 @@ Both approaches are equivalent. After reloading your shell, kubectl autocompleti
{{% tab name="Bash on macOS" %}}
{{< warning>}}
macOS includes Bash 3.2 by default. The kubectl completion script requires Bash 4.1+ and doesn't work with Bash 3.2. A possible way around this is to install a newer version of Bash on macOS (see instructions [here](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The below instructions only work if you are using Bash 4.1+.
{{< /warning >}}
### Introduction
The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
{{< warning>}}
there are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
{{< /warning >}}
However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
### Install bash-completion
You can install bash-completion with Homebrew:
{{< note >}}
As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
{{< /note >}}
You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
```shell
brew install bash-completion@2
```
{{< note >}}
The `@2` stands for bash-completion 2, which is required by the kubectl completion script (it doesn't work with bash-completion 1). In turn, bash-completion 2 requires Bash 4.1+, that's why you needed to upgrade Bash.
{{< /note >}}
As stated in the output of `brew install` ("Caveats" section), add the following lines to your `~/.bashrc` or `~/.bash_profile` file:
As stated in the output of this command, add the following to your `~/.bashrc` file:
```shell
export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r /usr/local/etc/profile.d/bash_completion.sh ]] && . /usr/local/etc/profile.d/bash_completion.sh
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
```
Reload your shell and verify that bash-completion is correctly installed by typing `type _init_completion`.
Reload your shell and verify that bash-completion v2 is correctly installed with `type _init_completion`.
### Enable kubectl autocompletion
You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways in which you can do this:
You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
- Source the completion script in your `~/.bashrc` file:
@@ -386,19 +403,19 @@ You now need to ensure that the kubectl completion script gets sourced in all yo
```
- Add the completion script to `/usr/local/etc/bash_completion.d`:
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:
```shell
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
```
- If you installed kubectl with Homebrew (as explained [here](#install-with-homebrew-on-macos)), then the completion script was automatically installed to `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
- If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
{{< note >}}
bash-completion (if installed with Homebrew) sources all the completion scripts in the directory that is set in the `BASH_COMPLETION_COMPAT_DIR` environment variable.
the Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
{{< /note >}}
All approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
In any case, after reloading your shell, kubectl completion should be working.
{{% /tab %}}
{{% tab name="Zsh" %}}
@@ -425,6 +442,9 @@ compinit
{{% /capture %}}
{{% capture whatsnext %}}
[Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* [Install Minikube](/docs/tasks/tools/install-minikube/)
* See the [getting started guides](/docs/setup/) for more about creating clusters.
* [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
* Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/)
{{% /capture %}}
content/en/docs/tasks/tools/install-minikube.md
+111 -42
View File
@@ -9,50 +9,120 @@ card:
{{% capture overview %}}
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your laptop.
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
{{% /capture %}}
{{% capture prerequisites %}}
VT-x or AMD-v virtualization must be enabled in your computer's BIOS. To check this on Linux run the following and verify the output is non-empty:
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
```shell
egrep --color 'vmx|svm' /proc/cpuinfo
```
{{% /tab %}}
{{% tab name="macOS" %}}
To check if virtualization is supported on macOS, run the following command on your terminal.
```
sysctl -a | grep machdep.cpu.features
```
If you see `VMX` in the output, the VT-x feature is supported on your OS.
{{% /tab %}}
{{% tab name="Windows" %}}
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
```
systeminfo
```
If you see the following output, virtualization is supported on Windows.
```
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
Virtualization Enabled In Firmware: Yes
Second Level Address Translation: Yes
Data Execution Prevention Available: Yes
```
If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
```
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
```
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture steps %}}
## Install a Hypervisor
# Installing minikube
If you do not already have a hypervisor installed, install one for your OS now:
{{< tabs name="tab_with_md" >}}
{{% tab name="Linux" %}}
Operating system | Supported hypervisors
:----------------|:---------------------
macOS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit)
Linux | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/)
Windows | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
### Install kubectl
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
• [KVM](https://www.linux-kvm.org/), which also uses QEMU
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker and a Linux environment but not a hypervisor.
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
{{< /note >}}
## Install kubectl
### Install Minikube using a package
* Install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/).
There are *experimental* packages for Minikube available; you can find Linux (AMD64) packages
from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page on GitHub.
## Install Minikube
Use your Linux's distribution's package tool to install a suitable package.
### macOS
### Install Minikube via direct download
If you're not installing via a package, you can download a stand-alone
binary and use that.
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
&& chmod +x minikube
```
Here's an easy way to add the Minikube executable to your path:
```shell
sudo install minikube /usr/local/bin
```
{{% /tab %}}
{{% tab name="macOS" %}}
### Install kubectl
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
• [HyperKit](https://github.com/moby/hyperkit)
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
• [VMware Fusion](https://www.vmware.com/products/fusion)
### Install Minikube
The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
```shell
brew cask install minikube
```
You can also install it on macOS by downloading a static binary:
You can also install it on macOS by downloading a stand-alone binary:
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
@@ -65,30 +135,25 @@ Here's an easy way to add the Minikube executable to your path:
sudo mv minikube /usr/local/bin
```
### Linux
{{% /tab %}}
{{% tab name="Windows" %}}
### Install kubectl
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
This document shows you how to install Minikube on Linux using a static binary. For alternative Linux installation methods, see [Other Ways to Install](https://github.com/kubernetes/minikube#other-ways-to-install) in the official Minikube GitHub repository.
Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
{{< /note >}}
You can install Minikube on Linux by downloading a static binary:
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
&& chmod +x minikube
```
Here's an easy way to add the Minikube executable to your path:
```shell
sudo cp minikube /usr/local/bin && rm minikube
```
### Windows
{{< note >}}
To run Minikube on Windows, you need to install [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) first, which can be run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
{{< /note >}}
### Install Minikube using Chocolatey
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
@@ -98,23 +163,27 @@ choco install minikube kubernetes-cli
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
#### Windows manual installation
### Install Minikube using an installer executable
To install Minikube manually on Windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe) and execute the installer.
### Install Minikube via direct download
To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
#### Windows Installer
{{% /tab %}}
{{< /tabs >}}
To install Minikube manually on windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest) and execute the installer.
{{% /capture %}}
{{% capture whatsnext %}}
* [Running Kubernetes Locally via Minikube](/docs/setup/minikube/)
* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
{{% /capture %}}
## Cleanup everything to start fresh
## Cleanup local state
If you have previously installed minikube, and run:
```shell
@@ -126,7 +195,7 @@ And this command returns an error:
machine does not exist
```
You need to wipe the configuration files:
You need to clear minikube's local state:
```shell
rm -rf ~/.minikube
minikube delete
```