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

Merge remote-tracking branch 'upstream/master' into dev-1.19

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-05-19 16:58:32 -04:00
parent 8e4d1d918d 58811dfd7c
commit 1f08c931df
172 changed files with 10181 additions and 4387 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/cluster-administration/flow-control.md
+24 -23
View File
@@ -131,14 +131,14 @@ classes:
namespace). These are important to isolate from other traffic because failures
in leader election cause their controllers to fail and restart, which in turn
causes more expensive traffic as the new controllers sync their informers.
* The `workload-high` priority level is for other requests from built-in
controllers.
* The `workload-low` priority level is for requests from any other service
account, which will typically include all requests from controllers runing in
Pods.
* The `global-default` priority level handles all other traffic, e.g.
interactive `kubectl` commands run by nonprivileged users.
@@ -150,7 +150,7 @@ are built in and may not be overwritten:
special `exempt` FlowSchema classifies all requests from the `system:masters`
group into this priority level. You may define other FlowSchemas that direct
other requests to this priority level, if appropriate.
* The special `catch-all` priority level is used in combination with the special
`catch-all` FlowSchema to make sure that every request gets some kind of
classification. Typically you should not rely on this catch-all configuration,
@@ -164,7 +164,7 @@ are built in and may not be overwritten:
## Resources
The flow control API involves two kinds of resources.
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
define the available isolation classes, the share of the available concurrency
budget that each can handle, and allow for fine-tuning queuing behavior.
[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
@@ -204,7 +204,7 @@ to balance progress between request flows.
The queuing configuration allows tuning the fair queuing algorithm for a
priority level. Details of the algorithm can be read in the [enhancement
proposal](#what-s-next), but in short:
proposal](#whats-next), but in short:
* Increasing `queues` reduces the rate of collisions between different flows, at
the cost of increased memory usage. A value of 1 here effectively disables the
@@ -233,20 +233,21 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl
an illustrative collection of numbers of elephants. See
https://play.golang.org/p/Gi0PLgVHiUg , which computes this table.
{{< table caption="Example Shuffle Sharding Configurations" >}}
|HandSize| Queues| 1 elephant| 4 elephants| 16 elephants|
|--------|-----------|------------|----------------|--------------------|
| 12| 32| 4.428838398950118e-09| 0.11431348830099144| 0.9935089607656024|
| 10| 32| 1.550093439632541e-08| 0.0626479840223545| 0.9753101519027554|
| 10| 64| 6.601827268370426e-12| 0.00045571320990370776| 0.49999929150089345|
| 9| 64| 3.6310049976037345e-11| 0.00045501212304112273| 0.4282314876454858|
| 8| 64| 2.25929199850899e-10| 0.0004886697053040446| 0.35935114681123076|
| 8| 128| 6.994461389026097e-13| 3.4055790161620863e-06| 0.02746173137155063|
| 7| 128| 1.0579122850901972e-11| 6.960839379258192e-06| 0.02406157386340147|
| 7| 256| 7.597695465552631e-14| 6.728547142019406e-08| 0.0006709661542533682|
| 6| 256| 2.7134626662687968e-12| 2.9516464018476436e-07| 0.0008895654642000348|
| 6| 512| 4.116062922897309e-14| 4.982983350480894e-09| 2.26025764343413e-05|
| 6| 1024| 6.337324016514285e-16| 8.09060164312957e-11| 4.517408062903668e-07|
{{< table caption = "Example Shuffle Sharding Configurations" >}}
HandSize | Queues | 1 elephant | 4 elephants | 16 elephants
|----------|-----------|------------|----------------|--------------------|
| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 |
| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 |
| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 |
| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 |
| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 |
| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 |
| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 |
| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 |
| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 |
| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 |
| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 |
{{< /table >}}
### FlowSchema
@@ -291,7 +292,7 @@ enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and
`X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request
and the priority level to which it was assigned, respectively. The API objects'
names are not included in these headers in case the requesting user does not
have permission to view them, so when debugging you can use a command like
have permission to view them, so when debugging you can use a command like
```shell
kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
@@ -363,7 +364,7 @@ poorly-behaved workloads that may be harming system health.
* `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how
long requests took to actually execute, grouped by the FlowSchema that matched the
request and the PriorityLevel to which it was assigned.
{{% /capture %}}
@@ -374,4 +375,4 @@ the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/maste
You can make suggestions and feature requests via [SIG API
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/configuration/overview.md
+1 -2
View File
@@ -59,8 +59,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
## Using Labels
content/en/docs/concepts/containers/overview.md
+2 -2
View File
@@ -9,9 +9,9 @@ weight: 1
{{% capture overview %}}
Containers are a technnology for packaging the (compiled) code for an
Containers are a technology for packaging the (compiled) code for an
application along with the dependencies it needs at run time. Each
container that you run is repeatable; the standardisation from having
container that you run is repeatable; the standardization from having
dependencies included means that you get the same behavior wherever you
run it.
content/en/docs/concepts/extend-kubernetes/operator.md
+2 -2
View File
@@ -106,7 +106,7 @@ as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
If there isn't an Operator in the ecosystem that implements the behavior you
want, you can code your own. In [What's next](#what-s-next) you'll find a few
want, you can code your own. In [What's next](#whats-next) you'll find a few
links to libraries and tools you can use to write your own cloud native
Operator.
@@ -129,4 +129,4 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+3 -3
View File
@@ -157,13 +157,13 @@ the three things:
1. **wait** (with a timeout) \
If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
Pods list, and the binding cycle of this Pod starts but directly blocks until it
gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
gets approved. If a timeout occurs, **wait** becomes **deny**
and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
plugins.
{{< note >}}
While any plugin can access the list of "waiting" Pods and approve them
(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
(see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
is approved, it is sent to the [PreBind](#pre-bind) phase.
{{< /note >}}
@@ -239,4 +239,4 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a
a scheduler profile and then define multiple profiles to fit various kinds of workload.
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/services-networking/dns-pod-service.md
+3 -5
View File
@@ -171,7 +171,7 @@ following pod-specific DNS policies. These policies are specified in the
- "`None`": It allows a Pod to ignore DNS settings from the Kubernetes
environment. All DNS settings are supposed to be provided using the
`dnsConfig` field in the Pod Spec.
See [Pod's DNS config](#pod-s-dns-config) subsection below.
See [Pod's DNS config](#pod-dns-config) subsection below.
{{< note >}}
"Default" is not the default DNS policy. If `dnsPolicy` is not
@@ -201,7 +201,7 @@ spec:
dnsPolicy: ClusterFirstWithHostNet
```
### Pod's DNS Config
### Pod's DNS Config {#pod-dns-config}
Pod's DNS Config allows users more control on the DNS settings for a Pod.
@@ -269,6 +269,4 @@ The availability of Pod DNS Config and DNS Policy "`None`"" is shown as below.
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/services-networking/ingress.md
+12 -13
View File
@@ -134,11 +134,10 @@ path types:
to the list of labels in the path split by the `/` separator. A request is a
match for path _p_ if every _p_ is an element-wise prefix of _p_ of the
request path.
{{< note >}}
If the last element of the path is a substring of the
last element in request path, it is not a match (for example:
`/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
{{< /note >}}
{{< note >}}
If the last element of the path is a substring of the last element in request path, it is not a match (for example: `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
{{< /note >}}
#### Multiple Matches
In some cases, multiple paths within an Ingress will match a request. In those
@@ -402,16 +401,16 @@ metadata:
spec:
tls:
- hosts:
- sslexample.foo.com
- sslexample.foo.com
secretName: testsecret-tls
rules:
- host: sslexample.foo.com
http:
paths:
- path: /
backend:
serviceName: service1
servicePort: 80
- host: sslexample.foo.com
http:
paths:
- path: /
backend:
serviceName: service1
servicePort: 80
```
{{< note >}}
content/en/docs/concepts/storage/persistent-volumes.md
+4 -4
View File
@@ -736,9 +736,9 @@ and need persistent storage, it is recommended that you use the following patter
`persistentVolumeClaim.storageClassName` field.
This will cause the PVC to match the right storage
class if the cluster has StorageClasses enabled by the admin.
- If the user does not provide a storage class name, leave the
`persistentVolumeClaim.storageClassName` field as nil. This will cause a
PV to be automatically provisioned for the user with the default StorageClass
- If the user does not provide a storage class name, leave the
`persistentVolumeClaim.storageClassName` field as nil. This will cause a
PV to be automatically provisioned for the user with the default StorageClass
in the cluster. Many cluster environments have a default StorageClass installed,
or administrators can create their own default StorageClass.
- In your tooling, watch for PVCs that are not getting bound after some time
@@ -759,4 +759,4 @@ and need persistent storage, it is recommended that you use the following patter
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/storage/volumes.md
+2 -2
View File
@@ -248,14 +248,14 @@ spec:
#### CSI Migration
{{< feature-state for_k8s_version="v1.14" state="alpha" >}}
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
The CSI Migration feature for Cinder, when enabled, shims all plugin operations
from the existing in-tree plugin to the `cinder.csi.openstack.org` Container
Storage Interface (CSI) Driver. In order to use this feature, the [Openstack Cinder CSI
Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack`
Alpha features must be enabled.
Beta features must be enabled.
### configMap {#configmap}
content/en/docs/concepts/workloads/controllers/deployment.md
+87 -80
View File
@@ -53,12 +53,13 @@ In this example:
In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
However, more sophisticated selection rules are possible,
as long as the Pod template itself satisfies the rule.
{{< note >}}
The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
and the values array contains only "value".
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
{{< /note >}}
{{< note >}}
The `.spec.selector.matchLabels` field is a map of {key,value} pairs.
A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
whose key field is "key" the operator is "In", and the values array contains only "value".
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
{{< /note >}}
* The `template` field contains the following sub-fields:
* The Pods are labeled `app: nginx`using the `.metadata.labels` field.
@@ -67,84 +68,92 @@ In this example:
[Docker Hub](https://hub.docker.com/) image at version 1.14.2.
* Create one container and name it `nginx` using the `.spec.template.spec.containers[0].name` field.
Follow the steps given below to create the above Deployment:
Before you begin, make sure your Kubernetes cluster is up and running.
Follow the steps given below to create the above Deployment:
Before you begin, make sure your Kubernetes cluster is up and running.
1. Create the Deployment by running the following command:
1. Create the Deployment by running the following command:
{{< note >}}
You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection.
For example, to see the commands executed in each Deployment revision.
{{< /note >}}
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
When you inspect the Deployments in your cluster, the following fields are displayed:
* `NAME` lists the names of the Deployments in the namespace.
* `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
* `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
* `AVAILABLE` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this:
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSet output shows the following fields:
* `NAME` lists the names of the ReplicaSets in the namespace.
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
* `CURRENT` displays how many replicas are currently running.
* `READY` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
randomly generated and uses the `pod-template-hash` as a seed.
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned:
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
The created ReplicaSet ensures that there are three `nginx` Pods.
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
You can specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`.
The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
{{< /note >}}
2. Run `kubectl get deployments` to check if the Deployment was created.
If the Deployment is still being created, the output is similar to the following:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
When you inspect the Deployments in your cluster, the following fields are displayed:
* `NAME` lists the names of the Deployments in the namespace.
* `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
* `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
* `AVAILABLE` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`.
The output is similar to:
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. Run the `kubectl get deployments` again a few seconds later.
The output is similar to this:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSet output shows the following fields:
* `NAME` lists the names of the ReplicaSets in the namespace.
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
* `CURRENT` displays how many replicas are currently running.
* `READY` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`.
The random string is randomly generated and uses the `pod-template-hash` as a seed.
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`.
The output is similar to:
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
The created ReplicaSet ensures that there are three `nginx` Pods.
{{< note >}}
You must specify an appropriate selector and Pod template labels in a Deployment
(in this case, `app: nginx`).
Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
{{< /note >}}
### Pod-template-hash label
{{< note >}}
{{< caution >}}
Do not change this label.
{{< /note >}}
{{< /caution >}}
The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
@@ -409,9 +418,7 @@ rolled back.
```
{{< note >}}
The Deployment controller stops the bad rollout automatically, and stops scaling up the new
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
Kubernetes by default sets the value to 25%.
The Deployment controller stops the bad rollout automatically, and stops scaling up the new ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. Kubernetes by default sets the value to 25%.
{{< /note >}}
* Get the description of the Deployment:
@@ -901,9 +908,9 @@ example, rollback the Deployment to its previous version.
{{< /note >}}
{{< note >}}
If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
deadline.
If you pause a Deployment, Kubernetes does not check progress against your specified deadline.
You can safely pause a Deployment in the middle of a rollout and resume without triggering
the condition for exceeding the deadline.
{{< /note >}}
You may experience transient errors with your Deployments, either due to a low timeout that you have set or
content/en/docs/concepts/workloads/controllers/statefulset.md
+1 -1
View File
@@ -156,7 +156,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
{{< note >}}
Cluster Domain will be set to `cluster.local` unless
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Stable Storage
content/en/docs/concepts/workloads/pods/init-containers.md
+2 -2
View File
@@ -241,7 +241,7 @@ myapp-pod 1/1 Running 0 9m
```
This simple example should provide some inspiration for you to create your own
init containers. [What's next](#what-s-next) contains a link to a more detailed example.
init containers. [What's next](#whats-next) contains a link to a more detailed example.
## Detailed behavior
@@ -325,4 +325,4 @@ reasons:
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+1 -1
View File
@@ -97,7 +97,7 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones,
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:&lt;any value&gt;" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
content/en/docs/contribute/review/for-approvers.md
+1 -2
View File
@@ -73,8 +73,7 @@ true:
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
enables chatbot-style commands to handle GitHub actions across the Kubernetes
organization, like [adding and removing
labels](#add-and-remove-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
The most common prow commands reviewers and approvers use are:
content/en/docs/reference/command-line-tools-reference/kubelet.md
+1133 -1133
View File
File diff suppressed because it is too large Load Diff
content/en/docs/reference/kubectl/overview.md
+18
View File
@@ -69,31 +69,49 @@ The following table includes short descriptions and the general syntax for all o
Operation | Syntax | Description
-------------------- | -------------------- | --------------------
`alpha` | `kubectl alpha SUBCOMMAND [flags]` | List the available commands that correspond to alpha features, which are not enabled in Kubernetes clusters by default.
`annotate` | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | Add or update the annotations of one or more resources.
`api-resources` | `kubectl api-resources [flags]` | List the API resources that are available.
`api-versions` | `kubectl api-versions [flags]` | List the API versions that are available.
`apply` | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin.
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin).
`auth` | `kubectl auth [flags] [options]` | Inspect authorization.
`autoscale` | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | Automatically scale the set of pods that are managed by a replication controller.
`certificate` | `kubectl certificate SUBCOMMAND [options]` | Modify certificate resources.
`cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
`completion` | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh).
`config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted.
`cordon` | `kubectl cordon NODE [options]` | Mark node as unschedulable.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers.
`create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
`delete` | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
`describe` | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | Display the detailed state of one or more resources.
`diff` | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.
`drain` | `kubectl drain NODE [options]` | Drain node in preparation for maintenance.
`edit` | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | Edit and update the definition of one or more resources on the server by using the default editor.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod.
`explain` | `kubectl explain [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
`expose` | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | Expose a replication controller, service, or pod as a new Kubernetes service.
`get` | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | List one or more resources.
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root.
`label` | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | Add or update the labels of one or more resources.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
`options` | `kubectl options` | List of global command-line options, which apply to all commands.
`patch` | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Update one or more fields of a resource by using the strategic merge patch process.
`plugin` | `kubectl plugin [flags] [options]` | Provides utilities for interacting with plugins.
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod.
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server.
`replace` | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin.
`rollout` | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets.
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | Run a specified image on the cluster.
`scale` | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | Update the size of the specified replication controller.
`set` | `kubectl set SUBCOMMAND [options]` | Configure application resources.
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes.
`top` | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage.
`uncordon` | `kubectl uncordon NODE [options]` | Mark node as schedulable.
`version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | Experimental: Wait for a specific condition on one or many resources.
Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation.
content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+4 -2
View File
@@ -325,7 +325,8 @@ deadlock conditions, kubeadm fails fast if `localhost:10255/healthz` (kubelet li
kubeadm relies on the kubelet to pull the control plane images and run them properly as static Pods.
After the control plane is up, kubeadm completes the tasks described in following paragraphs.
### (optional and alpha in v1.9) Write base kubelet configuration
### (optional) Write base kubelet configuration
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
@@ -516,7 +517,8 @@ Please note that:
access to CSR api during the `kubeadm init` process
- The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process
### (optional and alpha in v1.9) Write init kubelet configuration
### (optional) Write init kubelet configuration
{{< feature-state for_k8s_version="v1.9" state="alpha" >}}
If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`:
content/en/docs/setup/learning-environment/minikube.md
+124 -89
View File
@@ -37,116 +37,151 @@ See [Installing Minikube](/docs/tasks/tools/install-minikube/).
This brief demo guides you on how to start, use, and delete Minikube locally. Follow the steps given below to start and explore Minikube.
1. Start Minikube and create a cluster:
```shell
minikube start
```
The output is similar to this:
```
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
```
For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster).
```shell
minikube start
```
The output is similar to this:
```
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...
```
For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster).
2. Now, you can interact with your cluster using kubectl. For more information, see [Interacting with Your Cluster](#interacting-with-your-cluster).
Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`.
```shell
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
```
The output is similar to this:
```
deployment.apps/hello-minikube created
```
3. To access the `hello-minikube` Deployment, expose it as a Service:
```shell
kubectl expose deployment hello-minikube --type=NodePort --port=8080
```
The option `--type=NodePort` specifies the type of the Service.
Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`.
```shell
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
```
The output is similar to this:
```
deployment.apps/hello-minikube created
```
3. To access the `hello-minikube` Deployment, expose it as a Service:
```shell
kubectl expose deployment hello-minikube --type=NodePort --port=8080
```
The option `--type=NodePort` specifies the type of the Service.
The output is similar to this:
```
service/hello-minikube exposed
```
The output is similar to this:
```
service/hello-minikube exposed
```
4. The `hello-minikube` Pod is now launched but you have to wait until the Pod is up before accessing it via the exposed Service.
Check if the Pod is up and running:
```shell
kubectl get pod
```
If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s
```
If the output shows the `STATUS` as `Running`, the Pod is now up and running:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 1/1 Running 0 13s
```
Check if the Pod is up and running:
```shell
kubectl get pod
```
If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s
```
If the output shows the `STATUS` as `Running`, the Pod is now up and running:
```
NAME READY STATUS RESTARTS AGE
hello-minikube-3383150820-vctvh 1/1 Running 0 13s
```
5. Get the URL of the exposed Service to view the Service details:
```shell
minikube service hello-minikube --url
```
```shell
minikube service hello-minikube --url
```
6. To view the details of your local cluster, copy and paste the URL you got as the output, on your browser.
The output is similar to this:
```
Hostname: hello-minikube-7c77b68cff-8wdzq
The output is similar to this:
Pod Information:
-no pod information available-
```
Hostname: hello-minikube-7c77b68cff-8wdzq
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Pod Information:
-no pod information available-
Request Information:
client_address=172.17.0.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://192.168.99.100:8080/
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Headers:
Request Information:
client_address=172.17.0.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://192.168.99.100:8080/
Request Headers:
accept=*/*
host=192.168.99.100:30674
user-agent=curl/7.47.0
Request Body:
Request Body:
-no body in request-
```
If you no longer want the Service and cluster to run, you can delete them.
```
If you no longer want the Service and cluster to run, you can delete them.
7. Delete the `hello-minikube` Service:
```shell
kubectl delete services hello-minikube
```
The output is similar to this:
```
service "hello-minikube" deleted
```
```shell
kubectl delete services hello-minikube
```
The output is similar to this:
```
service "hello-minikube" deleted
```
8. Delete the `hello-minikube` Deployment:
```shell
kubectl delete deployment hello-minikube
```
The output is similar to this:
```
deployment.extensions "hello-minikube" deleted
```
```shell
kubectl delete deployment hello-minikube
```
The output is similar to this:
```
deployment.extensions "hello-minikube" deleted
```
9. Stop the local Minikube cluster:
```shell
minikube stop
```
The output is similar to this:
```
Stopping "minikube"...
"minikube" stopped.
```
For more information, see [Stopping a Cluster](#stopping-a-cluster).
```shell
minikube stop
```
The output is similar to this:
```
Stopping "minikube"...
"minikube" stopped.
```
For more information, see [Stopping a Cluster](#stopping-a-cluster).
10. Delete the local Minikube cluster:
```shell
minikube delete
```
@@ -193,8 +228,8 @@ For example the command would be.
minikube start --driver=<driver_name>
```
Minikube supports the following drivers:
{{< note >}}
See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install
{{< note >}}
See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install
plugins.
{{< /note >}}
content/en/docs/setup/production-environment/container-runtimes.md
+109 -34
View File
@@ -21,8 +21,8 @@ A flaw was found in the way runc handled system file descriptors when running co
A malicious container could use this flaw to overwrite contents of the runc binary and
consequently run arbitrary commands on the container host system.
Please refer to this link for more information about this issue
[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
Please refer to [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) for more
information about the issue.
{{< /caution >}}
### Applicability
@@ -70,29 +70,39 @@ Keep track of the latest verified Docker version in the Kubernetes release notes
Use the following commands to install Docker on your system:
{{< tabs name="tab-cri-docker-installation" >}}
{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
# Install Docker CE
{{< tab name="Ubuntu 16.04+" >}}
```shell
# (Install Docker CE)
## Set up the repository:
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install -y \
apt-transport-https ca-certificates curl software-properties-common gnupg2
```
### Add Docker’s official GPG key
```shell
# Add Docker’s official GPG key:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
```
### Add Docker apt repository.
```shell
# Add the Docker apt repository:
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
## Install Docker CE.
```shell
# Install Docker CE
apt-get update && apt-get install -y \
containerd.io=1.2.13-1 \
docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \
docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs)
```
# Setup daemon.
```shell
# Set up the Docker daemon
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
@@ -103,34 +113,48 @@ cat > /etc/docker/daemon.json <<EOF
"storage-driver": "overlay2"
}
EOF
```
```shell
mkdir -p /etc/systemd/system/docker.service.d
```
# Restart docker.
```shell
# Restart Docker
systemctl daemon-reload
systemctl restart docker
```
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
{{< tab name="CentOS/RHEL 7.4+" >}}
# Install Docker CE
```shell
# (Install Docker CE)
## Set up the repository
### Install required packages.
### Install required packages
yum install -y yum-utils device-mapper-persistent-data lvm2
```
### Add Docker repository.
```shell
## Add the Docker repository
yum-config-manager --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
## Install Docker CE.
```shell
# Install Docker CE
yum update -y && yum install -y \
containerd.io-1.2.13 \
docker-ce-19.03.8 \
docker-ce-cli-19.03.8
```
## Create /etc/docker directory.
```shell
## Create /etc/docker
mkdir /etc/docker
```
# Setup daemon.
```shell
# Set up the Docker daemon
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
@@ -144,12 +168,17 @@ cat > /etc/docker/daemon.json <<EOF
]
}
EOF
```
```shell
mkdir -p /etc/systemd/system/docker.service.d
```
```shell
# Restart Docker
systemctl daemon-reload
systemctl restart docker
```
{{< /tab >}}
{{< /tabs >}}
@@ -173,7 +202,7 @@ For more information, see the [CRI-O compatiblity matrix](https://github.com/cri
modprobe overlay
modprobe br_netfilter
# Setup required sysctl params, these persist across reboots.
# Set up required sysctl params, these persist across reboots.
cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
@@ -184,54 +213,79 @@ sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
{{< tab name="Debian" codelang="bash" >}}
{{< tab name="Debian" >}}
```shell
# Debian Unstable/Sid
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
```
```shell
# Debian Testing
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
```
```shell
# Debian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
```
```shell
# Raspbian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
```
# Install CRI-O
and then install CRI-O:
```shell
sudo apt-get install cri-o-1.17
```
{{< /tab >}}
{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}}
# Setup repository
{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}}
```shell
# Configure package repository
. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
sudo apt-get update
```
```shell
# Install CRI-O
sudo apt-get install cri-o-1.17
```
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
{{< tab name="CentOS/RHEL 7.4+" >}}
```shell
# Install prerequisites
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
```
```shell
# Install CRI-O
yum install --nogpgcheck -y cri-o
yum install -y cri-o
```
{{< /tab >}}
{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
{{< tab name="openSUSE Tumbleweed" >}}
```shell
sudo zypper install cri-o
```
{{< /tab >}}
{{< /tabs >}}
### Start CRI-O
```
```shell
systemctl daemon-reload
systemctl start crio
```
@@ -269,51 +323,72 @@ sysctl --system
### Install containerd
{{< tabs name="tab-cri-containerd-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
# Install containerd
{{< tab name="Ubuntu 16.04" >}}
```shell
# (Install containerd)
## Set up the repository
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
### Add Docker’s official GPG key
```shell
## Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
```
### Add Docker apt repository.
```shell
## Add Docker apt repository.
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
## Install containerd
apt-get update && apt-get install -y containerd.io
```
```shell
# Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
```shell
# Restart containerd
systemctl restart containerd
```
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
# Install containerd
{{< tab name="CentOS/RHEL 7.4+" >}}
```shell
# (Install containerd)
## Set up the repository
### Install required packages
yum install -y yum-utils device-mapper-persistent-data lvm2
### Add docker repository
```shell
## Add docker repository
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```shell
## Install containerd
yum update -y && yum install -y containerd.io
# Configure containerd
```shell
## Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
```shell
# Restart containerd
systemctl restart containerd
```
{{< /tab >}}
{{< /tabs >}}
content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+2 -2
View File
@@ -303,10 +303,10 @@ Below you can find installation instructions for some popular Pod network plugin
{{% tab name="Calico" %}}
[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.
By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the `kubeadm init` command using the `--pod-network-cidr=192.168.0.0/16` flag or via kubeadm's configuration.
Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration.
```shell
kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml
```
{{% /tab %}}
content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+2 -2
View File
@@ -122,8 +122,8 @@ option. Your cluster requirements may need a different configuration.
{{< /note >}}
{{< note >}}
Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
Some CNI network plugins require additional configuration, for example specifying the pod IP CIDR, while others do not.
See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
{{< /note >}}
content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+6 -4
View File
@@ -28,7 +28,7 @@ For information how to create a cluster with kubeadm once you have performed thi
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
* 2 CPUs or more
* Full network connectivity between all machines in the cluster (public or private network is fine)
* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) for more details.
* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-mac-address) for more details.
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
@@ -36,7 +36,7 @@ For information how to create a cluster with kubeadm once you have performed thi
{{% capture steps %}}
## Verify the MAC address and product_uuid are unique for every node
## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address}
* You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a`
* The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid`
@@ -210,12 +210,14 @@ yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
systemctl enable --now kubelet
```
**Note:**
**Notes:**
- Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it.
This is required to allow containers to access the host filesystem, which is needed by pod networks for example.
You have to do this until SELinux support is improved in the kubelet.
- You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm.
{{% /tab %}}
{{% tab name="Container Linux" %}}
Install CNI plugins (required for most pod network):
@@ -303,4 +305,4 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/setup/production-environment/tools/kubespray.md
+2 -2
View File
@@ -21,7 +21,7 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* openSUSE Leap 15
* continuous integration tests
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
{{% /capture %}}
@@ -119,4 +119,4 @@ When running the reset playbook, be sure not to accidentally target your product
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md).
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/access-application-cluster/access-cluster.md
+2 -2
View File
@@ -277,7 +277,7 @@ This shows the proxy-verb URL for accessing each service.
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at:
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.)
#### Manually constructing apiserver proxy URLs
@@ -376,4 +376,4 @@ There are several different proxies you may encounter when using Kubernetes:
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
will typically ensure that the latter types are setup correctly.
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+1 -1
View File
@@ -97,7 +97,7 @@ If needed, you can expand the **Advanced options** section where you can specify
Example:
```conf
```conf
release=1.0
tier=frontend
environment=pod
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+55 -29
View File
@@ -28,6 +28,7 @@ into the Kubernetes API by creating a
{{% /capture %}}
{{% capture steps %}}
## Create a CustomResourceDefinition
When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server
@@ -41,6 +42,7 @@ For example, if you save the following CustomResourceDefinition to `resourcedefi
{{< tabs name="CustomResourceDefinition_example_1" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
@@ -83,8 +85,10 @@ spec:
shortNames:
- ct
```
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
```yaml
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
@@ -129,6 +133,7 @@ spec:
replicas:
type: integer
```
{{% /tab %}}
{{< /tabs >}}
@@ -188,7 +193,7 @@ kubectl get crontab
Should print a list like this:
```console
```none
NAME AGE
my-new-cron-object 6s
```
@@ -205,7 +210,7 @@ kubectl get ct -o yaml
You should see that it contains the custom `cronSpec` and `image` fields
from the yaml you used to create it:
```console
```yaml
apiVersion: v1
kind: List
items:
@@ -228,14 +233,14 @@ metadata:
## Delete a CustomResourceDefinition
When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint
and **delete all custom objects stored in it**.
and delete all custom objects stored in it.
```shell
kubectl delete -f resourcedefinition.yaml
kubectl get crontabs
```
```console
```none
Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com)
```
@@ -362,7 +367,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables
* [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion)
* [Pruning](#preserving-unknown-fields)
### Pruning versus preserving unknown fields
### Pruning versus preserving unknown fields {#preserving-unknown-fields}
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
@@ -630,7 +635,9 @@ These fields can only be set with specific features enabled:
- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting).
Note: compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.
{{< note >}}
Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.
{{< /note >}}
The schema is defined in the CustomResourceDefinition. In the following example, the
CustomResourceDefinition applies the following validations on the custom object:
@@ -642,6 +649,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`:
{{< tabs name="CustomResourceDefinition_validation" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
@@ -676,8 +684,10 @@ spec:
shortNames:
- ct
```
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
```yaml
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
@@ -714,6 +724,7 @@ spec:
minimum: 1
maximum: 10
```
{{% /tab %}}
{{< /tabs >}}
@@ -852,7 +863,7 @@ spec:
replicas: 1
```
Note that defaulting happens on the object
Defaulting happens on the object
* in the request to the API server using the request version defaults,
* when reading from etcd using the storage version defaults,
@@ -895,9 +906,11 @@ columns are shown by the `kubectl get` command. You can customize these columns
CustomResourceDefinition. The following example adds the `Spec`, `Replicas`, and `Age`
columns.
1. Save the CustomResourceDefinition to `resourcedefinition.yaml`.
{{< tabs name="CustomResourceDefinition_printer_columns" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
Save the CustomResourceDefinition to `resourcedefinition.yaml`:
{{< tabs name="CustomResourceDefinition_printer_columns" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
@@ -942,8 +955,10 @@ spec:
type: date
jsonPath: .metadata.creationTimestamp
```
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
```yaml
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
@@ -986,31 +1001,34 @@ spec:
type: date
JSONPath: .metadata.creationTimestamp
```
{{% /tab %}}
{{< /tabs >}}
2. Create the CustomResourceDefinition:
{{% /tab %}}
{{< /tabs >}}
```shell
kubectl apply -f resourcedefinition.yaml
```
Create the CustomResourceDefinition:
3. Create an instance using the `my-crontab.yaml` from the previous section.
```shell
kubectl apply -f resourcedefinition.yaml
```
4. Invoke the server-side printing:
Create an instance using the `my-crontab.yaml` from the previous section.
```shell
kubectl get crontab my-new-cron-object
```
Invoke the server-side printing:
Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output:
```shell
kubectl get crontab my-new-cron-object
```
```
NAME SPEC REPLICAS AGE
my-new-cron-object * * * * * 1 7s
```
Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output:
```
NAME SPEC REPLICAS AGE
my-new-cron-object * * * * * 1 7s
```
{{< note >}}
The `NAME` column is implicit and does not need to be defined in the CustomResourceDefinition.
{{< /note >}}
#### Priority
@@ -1133,6 +1151,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`:
{{< tabs name="CustomResourceDefinition_scale" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
@@ -1184,8 +1203,10 @@ spec:
shortNames:
- ct
```
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
```yaml
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
@@ -1238,6 +1259,7 @@ spec:
# labelSelectorPath defines the JSONPath inside of a custom resource that corresponds to Scale.Status.Selector.
labelSelectorPath: .status.labelSelector
```
{{% /tab %}}
{{< /tabs >}}
@@ -1307,6 +1329,7 @@ Save the following CustomResourceDefinition to `resourcedefinition.yaml`:
{{< tabs name="CustomResourceDefinition_categories" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
@@ -1342,8 +1365,10 @@ spec:
categories:
- all
```
{{% /tab %}}
{{% tab name="apiextensions.k8s.io/v1beta1" %}}
```yaml
# Deprecated in v1.16 in favor of apiextensions.k8s.io/v1
apiVersion: apiextensions.k8s.io/v1beta1
@@ -1380,6 +1405,7 @@ spec:
categories:
- all
```
{{% /tab %}}
{{< /tabs >}}
@@ -1431,4 +1457,4 @@ crontabs/my-new-cron-object 3s
* Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a
CustomResourceDefinition.
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/administer-cluster/encrypt-data.md
+28 -22
View File
@@ -62,12 +62,12 @@ but not both in the same item).
The first provider in the list is used to encrypt resources going into storage. When reading
resources from storage each provider that matches the stored data attempts to decrypt the data in
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
is returned which prevents clients from accessing that resource.
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
is returned which prevents clients from accessing that resource.
{{< caution >}}
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
read that resource will fail until it is deleted or a valid decryption key is provided.
{{< /caution >}}
@@ -117,9 +117,9 @@ To create a new secret perform the following steps:
1. Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command:
```
head -c 32 /dev/urandom | base64
```
```shell
head -c 32 /dev/urandom | base64
```
2. Place that value in the secret field.
3. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
@@ -138,39 +138,42 @@ program to retrieve the contents of your secret.
1. Create a new secret called `secret1` in the `default` namespace:
```
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
```shell
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
2. Using the etcdctl commandline, read that secret out of etcd:
```
   ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
```
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
where `[...]` must be the additional arguments for connecting to the etcd server.
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
where `[...]` must be the additional arguments for connecting to the etcd server.
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
4. Verify the secret is correctly decrypted when retrieved via the API:
```
kubectl describe secret secret1 -n default
```
```shell
kubectl describe secret secret1 -n default
```
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
completely decode the secret.
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
completely decode the secret.
## Ensure all secrets are encrypted
Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
```
```shell
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
The command above reads all secrets and then updates them to apply server side encryption.
{{< note >}}
If an error occurs due to a conflicting write, retry the command.
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
{{< /note >}}
## Rotating a decryption key
@@ -206,7 +209,10 @@ resources:
secret: <BASE 64 ENCODED SECRET>
```
and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -`
and restart all `kube-apiserver` processes. Then run:
```shell
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
to force all secrets to be decrypted.
{{% /capture %}}
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+68 -68
View File
@@ -50,59 +50,59 @@ The upgrade workflow at high level is the following:
## Determine which version to upgrade to
1. Find the latest stable 1.18 version:
Find the latest stable 1.18 version:
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt update
apt-cache madison kubeadm
# find the latest 1.18 version in the list
# it should look like 1.18.x-00, where x is the latest patch
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# find the latest 1.18 version in the list
# it should look like 1.18.x-0, where x is the latest patch
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{< /tabs >}}
## Upgrading control plane nodes
### Upgrade the first control plane node
1. On your first control plane node, upgrade kubeadm:
- On your first control plane node, upgrade kubeadm:
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{< /tabs >}}
1. Verify that the download works and has the expected version:
- Verify that the download works and has the expected version:
```shell
kubeadm version
```
1. Drain the control plane node:
- Drain the control plane node:
```shell
# replace <cp-node-name> with the name of your control plane node
kubectl drain <cp-node-name> --ignore-daemonsets
```
1. On the control plane node, run:
- On the control plane node, run:
```shell
sudo kubeadm upgrade plan
@@ -145,13 +145,13 @@ The upgrade workflow at high level is the following:
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
{{< note >}}
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
{{</ note >}}
{{< note >}}
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used.
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadmkubeadm-certs).
{{</ note >}}
1. Choose a version to upgrade to, and run the appropriate command. For example:
- Choose a version to upgrade to, and run the appropriate command. For example:
```shell
# replace x with the patch version you picked for this upgrade
@@ -240,7 +240,7 @@ The upgrade workflow at high level is the following:
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
1. Manually upgrade your CNI provider plugin.
- Manually upgrade your CNI provider plugin.
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
Check the [addons](/docs/concepts/cluster-administration/addons/) page to
@@ -248,7 +248,7 @@ The upgrade workflow at high level is the following:
This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.
1. Uncordon the control plane node:
- Uncordon the control plane node:
```shell
# replace <cp-node-name> with the name of your control plane node
@@ -257,46 +257,46 @@ The upgrade workflow at high level is the following:
### Upgrade additional control plane nodes
1. Same as the first control plane node but use:
Same as the first control plane node but use:
```
sudo kubeadm upgrade node
```
```
sudo kubeadm upgrade node
```
instead of:
instead of:
```
sudo kubeadm upgrade apply
```
```
sudo kubeadm upgrade apply
```
Also `sudo kubeadm upgrade plan` is not needed.
Also `sudo kubeadm upgrade plan` is not needed.
### Upgrade kubelet and kubectl
1. Upgrade the kubelet and kubectl on all control plane nodes:
Upgrade the kubelet and kubectl on all control plane nodes:
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{< /tabs >}}
1. Restart the kubelet
Restart the kubelet
```shell
sudo systemctl restart kubelet
```
```shell
sudo systemctl restart kubelet
```
## Upgrade worker nodes
@@ -305,28 +305,28 @@ without compromising the minimum required capacity for running your workloads.
### Upgrade kubeadm
1. Upgrade kubeadm on all worker nodes:
- Upgrade kubeadm on all worker nodes:
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
apt-mark hold kubeadm
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{< /tabs >}}
### Drain the node
1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
```shell
# replace <node-to-drain> with the name of your node you are draining
@@ -343,7 +343,7 @@ without compromising the minimum required capacity for running your workloads.
### Upgrade the kubelet configuration
1. Call the following command:
- Call the following command:
```shell
sudo kubeadm upgrade node
@@ -351,26 +351,26 @@ without compromising the minimum required capacity for running your workloads.
### Upgrade kubelet and kubectl
1. Upgrade the kubelet and kubectl on all worker nodes:
- Upgrade the kubelet and kubectl on all worker nodes:
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in 1.18.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
apt-mark hold kubelet kubectl
-
# since apt-get version 1.1 you can also use the following method
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
# replace x in 1.18.x-0 with the latest patch version
yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
{{% /tab %}}
{{< /tabs >}}
1. Restart the kubelet
- Restart the kubelet
```shell
sudo systemctl restart kubelet
@@ -378,7 +378,7 @@ without compromising the minimum required capacity for running your workloads.
### Uncordon the node
1. Bring the node back online by marking it schedulable:
- Bring the node back online by marking it schedulable:
```shell
# replace <node-to-drain> with the name of your node
@@ -441,4 +441,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
`kubeadm upgrade node` does the following on worker nodes:
- Fetches the kubeadm `ClusterConfiguration` from the cluster.
- Upgrades the kubelet configuration for this node.
- Upgrades the kubelet configuration for this node.
content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+8 -8
View File
@@ -70,10 +70,10 @@ and is overridden by command-line flags. Unspecified values in the new configura
will receive default values appropriate to the configuration version
(e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags.
The status of the Node's kubelet configuration is reported via
The status of the Node's kubelet configuration is reported via
`Node.Spec.Status.Config`. Once you have updated a Node to use the new
ConfigMap, you can observe this status to confirm that the Node is using the
intended configuration.
intended configuration.
This document describes editing Nodes using `kubectl edit`.
There are other ways to modify a Node's spec, including `kubectl patch`, for
@@ -136,7 +136,7 @@ adapt the steps if you prefer to extract the `kubeletconfig` subobject manually.
1. Choose a Node to reconfigure. In this example, the name of this Node is
referred to as `NODE_NAME`.
2. Start the kubectl proxy in the background using the following command:
2. Start the kubectl proxy in the background using the following command:
```bash
kubectl proxy --port=8001 &
@@ -236,8 +236,8 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and
The`lastKnownGood` configuration might not be present if it is set to its default value,
the local config deployed with the node. The status will update `lastKnownGood` to
match a valid `assigned` config after the kubelet becomes comfortable with the config.
The details of how the kubelet determines a config should become the `lastKnownGood` are
match a valid `assigned` config after the kubelet becomes comfortable with the config.
The details of how the kubelet determines a config should become the `lastKnownGood` are
not guaranteed by the API, but is currently implemented as a 10-minute grace period.
You can use the following command (using `jq`) to filter down
@@ -287,7 +287,7 @@ by eye).
If an error occurs, the kubelet reports it in the `Node.Status.Config.Error`
structure. Possible errors are listed in
[Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages).
[Understanding Node.Status.Config.Error messages](#understanding-node-config-status-errors).
You can search for the identical text in the kubelet log for additional details
and context about the error.
@@ -355,7 +355,7 @@ metadata and checkpoints. The structure of the kubelet's checkpointing directory
| - ...
```
## Understanding Node.Status.Config.Error messages
## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors}
The following table describes error messages that can occur
when using Dynamic Kubelet Config. You can search for the identical text
@@ -379,4 +379,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+3 -3
View File
@@ -173,7 +173,7 @@ For example: in Centos, you can do this using the tuned toolset.
Memory pressure at the node level leads to System OOMs which affects the entire
node and all pods running on it. Nodes can go offline temporarily until memory
has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet
provides [`Out of Resource`](./out-of-resource.md) management. Evictions are
provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are
supported for `memory` and `ephemeral-storage` only. By reserving some memory via
`--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory
availability on the node drops below the reserved value. Hypothetically, if
@@ -190,7 +190,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods.
`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
by evicting pods whenever the overall usage across all pods exceeds
`Allocatable`. More details on eviction policy can be found
[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by
[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
@@ -251,4 +251,4 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
exceed their reservation, `kubelet` evicts pods whenever the overall node memory
usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
-3
View File
@@ -180,9 +180,6 @@ The output shows that the Pod status is Pending. That is, the Pod has not been
scheduled to run on any Node, and it will remain in the Pending state indefinitely:
```shell
kubectl get pod cpu-demo-2 --namespace=cpu-example
```
```
NAME READY STATUS RESTARTS AGE
cpu-demo-2 0/1 Pending 0 7m
content/en/docs/tasks/configure-pod-container/configure-runasusername.md
+5 -1
View File
@@ -16,6 +16,10 @@ This page shows how to use the `runAsUserName` setting for Pods and containers t
You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled.
{{% /capture %}}
{{% capture steps %}}
## Set the Username for a Pod
To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
@@ -118,4 +122,4 @@ For more information about these limtations, check [here](https://support.micros
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/configure-service-account.md
+34 -16
View File
@@ -183,27 +183,38 @@ The content of `token` is elided here.
## Add ImagePullSecrets to a service account
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
Next, verify it has been created. For example:
### Create an imagePullSecret
```shell
kubectl get secrets myregistrykey
```
- Create an imagePullSecret, as described in [Specifying ImagePullSecrets on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
The output is similar to this:
```shell
kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
--docker-email=DUMMY_DOCKER_EMAIL
```
```
NAME TYPE DATA AGE
myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
```
- Verify it has been created.
```shell
kubectl get secrets myregistrykey
```
The output is similar to this:
```
NAME TYPE DATA AGE
myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
```
### Add image pull secret to service account
Next, modify the default service account for the namespace to use this secret as an imagePullSecret.
```shell
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
```
Interactive version requires manual edit:
You can instead use `kubectl edit`, or manually edit the YAML manifests as shown below:
```shell
kubectl get serviceaccounts default -o yaml > ./sa.yaml
@@ -248,12 +259,19 @@ Finally replace the serviceaccount with the new updated `sa.yaml` file
kubectl replace serviceaccount default -f ./sa.yaml
```
Now, any new pods created in the current namespace will have this added to their spec:
### Verify imagePullSecrets was added to pod spec
```yaml
spec:
imagePullSecrets:
- name: myregistrykey
Now, when a new Pod is created in the current namespace and using the default ServiceAccount, the new Pod has its `spec.imagePullSecrets` field set automatically:
```shell
kubectl run nginx --image=nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
```
The output is:
```
myregistrykey
```
<!--## Adding Secrets to a service account.
content/en/docs/tasks/debug-application-cluster/debug-service.md
+39 -27
View File
@@ -45,8 +45,7 @@ probably debugging your own Service you can substitute your own details, or you
can follow along and get a second data point.
```shell
kubectl run hostnames --image=k8s.gcr.io/serve_hostname \
--replicas=3
kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname
```
```none
deployment.apps/hostnames created
@@ -54,6 +53,14 @@ deployment.apps/hostnames created
`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
Let's scale the deployment to 3 replicas.
```shell
kubectl scale deployment hostnames --replicas=3
```
```none
deployment.apps/hostnames scaled
```
{{< note >}}
This is the same as if you had started the Deployment with the following
YAML:
@@ -62,30 +69,32 @@ YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: hostnames
name: hostnames
spec:
selector:
matchLabels:
run: hostnames
app: hostnames
replicas: 3
template:
metadata:
labels:
run: hostnames
app: hostnames
spec:
containers:
- name: hostnames
image: k8s.gcr.io/serve_hostname
```
The label "run" is automatically set by `kubectl run` to the name of the
The label "app" is automatically set by `kubectl create deployment` to the name of the
Deployment.
{{< /note >}}
You can confirm your Pods are running:
```shell
kubectl get pods -l run=hostnames
kubectl get pods -l app=hostnames
```
```none
NAME READY STATUS RESTARTS AGE
@@ -98,7 +107,7 @@ You can also confirm that your Pods are serving. You can get the list of
Pod IP addresses and test them directly.
```shell
kubectl get pods -l run=hostnames \
kubectl get pods -l app=hostnames \
-o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'
```
```none
@@ -122,9 +131,9 @@ done
This should produce something like:
```
hostnames-0uton
hostnames-bvc05
hostnames-yp2kp
hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok
```
If you are not getting the responses you expect at this point, your Pods
@@ -193,10 +202,12 @@ As before, this is the same as if you had started the Service with YAML:
apiVersion: v1
kind: Service
metadata:
labels:
app: hostnames
name: hostnames
spec:
selector:
run: hostnames
app: hostnames
ports:
- name: default
protocol: TCP
@@ -345,9 +356,9 @@ done
This should produce something like:
```
hostnames-0uton
hostnames-bvc05
hostnames-yp2kp
hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok
```
If your Service is working, you should get correct responses. If not, there
@@ -373,7 +384,7 @@ kubectl get service hostnames -o json
"resourceVersion": "347189",
"creationTimestamp": "2015-07-07T15:24:29Z",
"labels": {
"run": "hostnames"
"app": "hostnames"
}
},
"spec": {
@@ -387,7 +398,7 @@ kubectl get service hostnames -o json
}
],
"selector": {
"run": "hostnames"
"app": "hostnames"
},
"clusterIP": "10.0.1.175",
"type": "ClusterIP",
@@ -414,16 +425,16 @@ actually being selected by the Service.
Earlier you saw that the Pods were running. You can re-check that:
```shell
kubectl get pods -l run=hostnames
kubectl get pods -l app=hostnames
```
```none
NAME READY STATUS RESTARTS AGE
hostnames-0uton 1/1 Running 0 1h
hostnames-bvc05 1/1 Running 0 1h
hostnames-yp2kp 1/1 Running 0 1h
hostnames-632524106-bbpiw 1/1 Running 0 1h
hostnames-632524106-ly40y 1/1 Running 0 1h
hostnames-632524106-tlaok 1/1 Running 0 1h
```
The `-l run=hostnames` argument is a label selector - just like our Service
The `-l app=hostnames` argument is a label selector - just like our Service
has.
The "AGE" column says that these Pods are about an hour old, which implies that
@@ -448,7 +459,8 @@ your Service. If the `ENDPOINTS` column is `<none>`, you should check that
the `spec.selector` field of your Service actually selects for
`metadata.labels` values on your Pods. A common mistake is to have a typo or
other error, such as the Service selecting for `app=hostnames`, but the
Deployment specifying `run=hostnames`.
Deployment specifying `run=hostnames`, as in versions previous to 1.18, where
the `kubectl run` command could have been also used to create a Deployment.
## Are the Pods working?
@@ -473,9 +485,9 @@ done
This should produce something like:
```
hostnames-0uton
hostnames-bvc05
hostnames-yp2kp
hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok
```
You expect each Pod in the Endpoints list to return its own hostname. If
@@ -617,7 +629,7 @@ IP from one of your Nodes:
curl 10.0.1.175:80
```
```none
hostnames-0uton
hostnames-632524106-bbpiw
```
If this fails and you are using the userspace proxy, you can try accessing the
@@ -631,7 +643,7 @@ examples it is "48577". Now connect to that:
curl localhost:48577
```
```none
hostnames-yp2kp
hostnames-632524106-tlaok
```
If this still fails, look at the `kube-proxy` logs for specific lines like:
content/en/docs/tasks/example-task-template.md
+3 -5
View File
@@ -9,7 +9,7 @@ toc_hide: true
{{% capture overview %}}
{{< note >}}
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document.
{{< /note >}}
This page shows how to ...
@@ -29,7 +29,7 @@ This page shows how to ...
## Doing ...
1. Do this.
1. Do this next. Possibly read this [related explanation](...).
1. Do this next. Possibly read this [related explanation](#).
{{% /capture %}}
@@ -49,6 +49,4 @@ Here's an interesting thing to know about the steps you just did.
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Task template](/docs/home/contribute/page-templates/#task_template) for how to use this template.
{{% /capture %}}
{{% /capture %}}
content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+51 -26
View File
@@ -146,7 +146,7 @@ is exposed:
my-app
39528$vdg7Jb
```
## Define container environment variables using Secret data
### Define a container environment variable with data from a single Secret
@@ -157,40 +157,56 @@ is exposed:
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.
* 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:
* 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`
* In your shell, display the content of `SECRET_USERNAME` container environment variable
```shell
kubectl exec -it env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
```
The output is
```shell
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'
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.
* 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
kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
```
* In your shell, display the container environment variables
```shell
kubectl exec -it envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
```
The output is
```shell
DB_USERNAME=db-admin
BACKEND_USERNAME=backend-admin
```
* 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
@@ -200,24 +216,33 @@ 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.
* 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.
* In your shell, display `username` and `password` container environment variables
````shell
kubectl exec -it envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password"'
````
The output is
````shell
username: my-app
password: 39528$vdg7Jb
````
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+12 -13
View File
@@ -46,13 +46,12 @@ Kustomize is a tool for customizing Kubernetes configurations. It has the follow
### 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.
ConfigMaps and Secrets hold configuration or sensitive data that are used by other Kubernetes objects, such as Pods. The source of truth of ConfigMaps or Secrets are usually external to a cluster, such as a `.properties` file or an SSH keyfile.
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.
To generate a ConfigMap from a file, add an entry to the `files` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.properties` file:
```shell
# Create a application.properties file
@@ -68,7 +67,7 @@ configMapGenerator:
EOF
```
The generated ConfigMap can be checked by the following command:
The generated ConfigMap can be examined with the following command:
```shell
kubectl kustomize ./
@@ -86,7 +85,7 @@ 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.
ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `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
@@ -103,7 +102,7 @@ The generated ConfigMap can be checked by the following command:
kubectl kustomize ./
```
The generated ConfigMap is
The generated ConfigMap is:
```yaml
apiVersion: v1
@@ -116,7 +115,7 @@ metadata:
#### 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.
You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to the `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
@@ -145,7 +144,7 @@ metadata:
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.
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
@@ -172,7 +171,7 @@ 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.
The generated ConfigMaps and Secrets have a content hash suffix appended. This ensures that a new ConfigMap or Secret is generated when the contents are 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
@@ -209,7 +208,7 @@ metadata:
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
* setting the same namespace for all Resources
* adding the same name prefix or suffix
* adding the same set of labels
* adding the same set of annotations
@@ -289,7 +288,7 @@ Kustomize offers composing Resources from different files and applying patches o
#### 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.
Here is an example of an NGINX application comprised of a Deployment and a Service:
```shell
# Create a deployment.yaml file
@@ -339,11 +338,11 @@ resources:
EOF
```
The Resources from `kubectl kustomize ./` contains both the Deployment and the Service objects.
The Resources from `kubectl kustomize ./` contain both the Deployment and the Service objects.
#### Customizing
On top of Resources, one can apply different customizations by applying patches. Kustomize supports different patching
Patches can be used to apply different customizations to Resources. 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
content/en/docs/tasks/tools/install-kubectl.md
+39 -20
View File
@@ -65,6 +65,7 @@ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
@@ -89,24 +90,30 @@ snap install kubectl --classic
kubectl version --client
```
{{% /tab %}}
{{% tab name="Homebrew" %}}
If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
```shell
brew install kubectl
kubectl version --client
```
{{% /tab %}}
{{< /tabs >}}
## 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"
```
@@ -129,6 +136,7 @@ kubectl version --client
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
```
@@ -144,8 +152,9 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
```
brew install kubectl
```
or
or
```
brew install kubernetes-cli
```
@@ -188,11 +197,13 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
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 --client
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
@@ -208,10 +219,11 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
{{< note >}}If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.{{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file
{{< note >}}If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
{{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file.
2. Test to ensure the version you installed is up-to-date:
@@ -219,11 +231,14 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
kubectl version --client
```
{{< note >}}Updating the installation is performed by rerunning the two commands listed in step 1.{{< /note >}}
{{< note >}}
Updating the installation is performed by rerunning the two commands listed in step 1.
{{< /note >}}
### 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.
1. 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" %}}
@@ -236,6 +251,8 @@ To install kubectl on Windows you can use either [Chocolatey](https://chocolatey
{{% /tab %}}
{{< /tabs >}}
2. Test to ensure the version you installed is up-to-date:
```
@@ -265,13 +282,14 @@ To install kubectl on Windows you can use either [Chocolatey](https://chocolatey
New-Item config -type file
```
{{< note >}}Edit the config file with a text editor of your choice, such as Notepad.{{< /note >}}
{{< note >}}Edit the config file with a text editor of your choice, such as Notepad.{{< /note >}}
## Download as part of the Google Cloud SDK
You can install kubectl as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the `kubectl` installation command:
```
@@ -293,6 +311,7 @@ Check that kubectl is properly configured by getting the cluster state:
```shell
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 configured correctly or is not able to connect to a Kubernetes cluster.
@@ -350,18 +369,17 @@ You now need to ensure that the kubectl completion script gets sourced in all yo
```shell
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Add the completion script to the `/etc/bash_completion.d` directory:
```shell
kubectl completion bash >/etc/bash_completion.d/kubectl
```
- If you have an alias for kubectl, you can extend shell completion to work with that alias:
If you have an alias for kubectl, you can extend shell completion to work with that alias:
```shell
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
```shell
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
```
{{< note >}}
bash-completion sources all completion scripts in `/etc/bash_completion.d`.
@@ -382,7 +400,7 @@ The kubectl completion script for Bash can be generated with `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).
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 >}}
### Upgrade Bash
@@ -454,9 +472,9 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
- 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 >}}
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 >}}
{{< note >}}
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 >}}
In any case, after reloading your shell, kubectl completion should be working.
{{% /tab %}}
@@ -489,6 +507,7 @@ compinit
{{% /tab %}}
{{< /tabs >}}
{{% /capture %}}
{{% capture whatsnext %}}
content/en/docs/templates/feature-state-alpha.txt
Vendored
-8
View File
@@ -1,8 +0,0 @@
This feature is currently in a *alpha* state, meaning:
* The version names contain alpha (e.g. v1alpha1).
* Might be buggy. Enabling the feature may expose bugs. Disabled by default.
* Support for feature may be dropped at any time without notice.
* The API may change in incompatible ways in a later software release without notice.
* Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
content/en/docs/templates/feature-state-beta.txt
Vendored
-8
View File
@@ -1,8 +0,0 @@
This feature is currently in a *beta* state, meaning:
* The version names contain beta (e.g. v2beta3).
* Code is well tested. Enabling the feature is considered safe. Enabled by default.
* Support for the overall feature will not be dropped, though details may change.
* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.**
content/en/docs/templates/feature-state-deprecated.txt
Vendored
-2
View File
@@ -1,2 +0,0 @@
This feature is *deprecated*. For more information on this state, see the [Kubernetes Deprecation Policy](/docs/reference/deprecation-policy/).
content/en/docs/templates/feature-state-stable.txt
Vendored
-5
View File
@@ -1,5 +0,0 @@
This feature is *stable*, meaning:
* The version name is vX where X is an integer.
* Stable versions of features will appear in released software for many subsequent versions.
content/en/docs/templates/index.md
Vendored
-13
View File
@@ -1,13 +0,0 @@
---
headless: true
resources:
- src: "*alpha*"
title: "alpha"
- src: "*beta*"
title: "beta"
- src: "*deprecated*"
title: "deprecated"
- src: "*stable*"
title: "stable"
---
content/en/docs/tutorials/stateful-application/zookeeper.md
-1
View File
@@ -723,7 +723,6 @@ unhealthy. You should use liveness probes to notify Kubernetes
that your application's processes are unhealthy and it should restart them.
The Pod `template` for the `zk` `StatefulSet` specifies a liveness probe.
``
```yaml
livenessProbe:
content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
+6 -6
View File
@@ -11,9 +11,9 @@ card:
---
{{% capture overview %}}
This tutorial builds upon the [PHP Guestbook with Redis](../guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components:
This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components:
* A running instance of the [PHP Guestbook with Redis tutorial](../guestbook)
* A running instance of the [PHP Guestbook with Redis tutorial](/docs/tutorials/stateless-application/guestbook)
* Elasticsearch and Kibana
* Filebeat
* Metricbeat
@@ -36,16 +36,16 @@ This tutorial builds upon the [PHP Guestbook with Redis](../guestbook) tutorial.
Additionally you need:
* A running deployment of the [PHP Guestbook with Redis](../guestbook) tutorial.
* A running deployment of the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial.
* A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co), run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
* A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co), run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts).
{{% /capture %}}
{{% capture lessoncontent %}}
## Start up the PHP Guestbook with Redis
This tutorial builds on the [PHP Guestbook with Redis](../guestbook) tutorial. If you have the guestbook application running, then you can monitor that. If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps. Come back to this page when you have the guestbook running.
This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. If you have the guestbook application running, then you can monitor that. If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps. Come back to this page when you have the guestbook running.
## Add a Cluster role binding
Create a [cluster level role binding](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) so that you can deploy kube-state-metrics and the Beats at the cluster level (in kube-system).
@@ -403,4 +403,4 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
* Read more about [logging architecture](/docs/concepts/cluster-administration/logging/)
* Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/)
* Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
{{% /capture %}}
{{% /capture %}}