Merge master into dev-1.21 to keep in sync - SIG-Release 1.21 Docs team 3/17/21
Fixed merge conflict with /docs/reference/command-line-tools-reference/kube-apiserver.md and preferred master
This commit is contained in:
Rey Lejano
@@ -31,7 +31,7 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
|
||||
There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}:
|
||||
|
||||
1. The kubelet on a node self-registers to the control plane
|
||||
2. You, or another human user, manually add a Node object
|
||||
2. You (or another human user) manually add a Node object
|
||||
|
||||
After you create a Node object, or the kubelet on a node self-registers, the
|
||||
control plane checks whether the new Node object is valid. For example, if you
|
||||
@@ -52,8 +52,8 @@ try to create a Node from the following JSON manifest:
|
||||
|
||||
Kubernetes creates a Node object internally (the representation). Kubernetes checks
|
||||
that a kubelet has registered to the API server that matches the `metadata.name`
|
||||
field of the Node. If the node is healthy (if all necessary services are running),
|
||||
it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
|
||||
field of the Node. If the node is healthy (i.e. all necessary services are running),
|
||||
then it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
|
||||
until it becomes healthy.
|
||||
|
||||
{{< note >}}
|
||||
@@ -96,14 +96,14 @@ You can create and modify Node objects using
|
||||
When you want to create Node objects manually, set the kubelet flag `--register-node=false`.
|
||||
|
||||
You can modify Node objects regardless of the setting of `--register-node`.
|
||||
For example, you can set labels on an existing Node, or mark it unschedulable.
|
||||
For example, you can set labels on an existing Node or mark it unschedulable.
|
||||
|
||||
You can use labels on Nodes in conjunction with node selectors on Pods to control
|
||||
scheduling. For example, you can constrain a Pod to only be eligible to run on
|
||||
a subset of the available nodes.
|
||||
|
||||
Marking a node as unschedulable prevents the scheduler from placing new pods onto
|
||||
that Node, but does not affect existing Pods on the Node. This is useful as a
|
||||
that Node but does not affect existing Pods on the Node. This is useful as a
|
||||
preparatory step before a node reboot or other maintenance.
|
||||
|
||||
To mark a Node unschedulable, run:
|
||||
@@ -179,14 +179,14 @@ The node condition is represented as a JSON object. For example, the following s
|
||||
]
|
||||
```
|
||||
|
||||
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
|
||||
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
|
||||
|
||||
The node controller does not force delete pods until it is confirmed that they have stopped
|
||||
running in the cluster. You can see the pods that might be running on an unreachable node as
|
||||
being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the
|
||||
underlying infrastructure if a node has permanently left a cluster, the cluster administrator
|
||||
may need to delete the node object by hand. Deleting the node object from Kubernetes causes
|
||||
all the Pod objects running on the node to be deleted from the API server, and frees up their
|
||||
may need to delete the node object by hand. Deleting the node object from Kubernetes causes
|
||||
all the Pod objects running on the node to be deleted from the API server and frees up their
|
||||
names.
|
||||
|
||||
The node lifecycle controller automatically creates
|
||||
@@ -199,7 +199,7 @@ for more details.
|
||||
|
||||
### Capacity and Allocatable {#capacity}
|
||||
|
||||
Describes the resources available on the node: CPU, memory and the maximum
|
||||
Describes the resources available on the node: CPU, memory, and the maximum
|
||||
number of pods that can be scheduled onto the node.
|
||||
|
||||
The fields in the capacity block indicate the total amount of resources that a
|
||||
@@ -225,18 +225,19 @@ CIDR block to the node when it is registered (if CIDR assignment is turned on).
|
||||
|
||||
The second is keeping the node controller's internal list of nodes up to date with
|
||||
the cloud provider's list of available machines. When running in a cloud
|
||||
environment, whenever a node is unhealthy, the node controller asks the cloud
|
||||
environment and whenever a node is unhealthy, the node controller asks the cloud
|
||||
provider if the VM for that node is still available. If not, the node
|
||||
controller deletes the node from its list of nodes.
|
||||
|
||||
The third is monitoring the nodes' health. The node controller is
|
||||
responsible for updating the NodeReady condition of NodeStatus to
|
||||
ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
|
||||
receiving heartbeats for some reason, for example due to the node being down), and then later evicting
|
||||
all the pods from the node (using graceful termination) if the node continues
|
||||
to be unreachable. (The default timeouts are 40s to start reporting
|
||||
ConditionUnknown and 5m after that to start evicting pods.) The node controller
|
||||
checks the state of each node every `--node-monitor-period` seconds.
|
||||
responsible for:
|
||||
- Updating the NodeReady condition of NodeStatus to ConditionUnknown when a node
|
||||
becomes unreachable, as the node controller stops receiving heartbeats for some
|
||||
reason such as the node being down.
|
||||
- Evicting all the pods from the node using graceful termination if
|
||||
the node continues to be unreachable. The default timeouts are 40s to start
|
||||
reporting ConditionUnknown and 5m after that to start evicting pods.
|
||||
The node controller checks the state of each node every `--node-monitor-period` seconds.
|
||||
|
||||
#### Heartbeats
|
||||
|
||||
@@ -252,13 +253,14 @@ of the node heartbeats as the cluster scales.
|
||||
The kubelet is responsible for creating and updating the `NodeStatus` and
|
||||
a Lease object.
|
||||
|
||||
- The kubelet updates the `NodeStatus` either when there is change in status,
|
||||
- The kubelet updates the `NodeStatus` either when there is change in status
|
||||
or if there has been no update for a configured interval. The default interval
|
||||
for `NodeStatus` updates is 5 minutes (much longer than the 40 second default
|
||||
timeout for unreachable nodes).
|
||||
for `NodeStatus` updates is 5 minutes, which is much longer than the 40 second default
|
||||
timeout for unreachable nodes.
|
||||
- The kubelet creates and then updates its Lease object every 10 seconds
|
||||
(the default update interval). Lease updates occur independently from the
|
||||
`NodeStatus` updates. If the Lease update fails, the kubelet retries with exponential backoff starting at 200 milliseconds and capped at 7 seconds.
|
||||
`NodeStatus` updates. If the Lease update fails, the kubelet retries with
|
||||
exponential backoff starting at 200 milliseconds and capped at 7 seconds.
|
||||
|
||||
#### Reliability
|
||||
|
||||
@@ -269,23 +271,24 @@ from more than 1 node per 10 seconds.
|
||||
The node eviction behavior changes when a node in a given availability zone
|
||||
becomes unhealthy. The node controller checks what percentage of nodes in the zone
|
||||
are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at
|
||||
the same time. If the fraction of unhealthy nodes is at least
|
||||
`--unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced:
|
||||
if the cluster is small (i.e. has less than or equal to
|
||||
`--large-cluster-size-threshold` nodes - default 50) then evictions are
|
||||
stopped, otherwise the eviction rate is reduced to
|
||||
`--secondary-node-eviction-rate` (default 0.01) per second. The reason these
|
||||
policies are implemented per availability zone is because one availability zone
|
||||
might become partitioned from the master while the others remain connected. If
|
||||
your cluster does not span multiple cloud provider availability zones, then
|
||||
there is only one availability zone (the whole cluster).
|
||||
the same time:
|
||||
- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
|
||||
(default 0.55), then the eviction rate is reduced.
|
||||
- If the cluster is small (i.e. has less than or equal to
|
||||
`--large-cluster-size-threshold` nodes - default 50), then evictions are stopped.
|
||||
- Otherwise, the eviction rate is reduced to `--secondary-node-eviction-rate`
|
||||
(default 0.01) per second.
|
||||
The reason these policies are implemented per availability zone is because one
|
||||
availability zone might become partitioned from the master while the others remain
|
||||
connected. If your cluster does not span multiple cloud provider availability zones,
|
||||
then there is only one availability zone (i.e. the whole cluster).
|
||||
|
||||
A key reason for spreading your nodes across availability zones is so that the
|
||||
workload can be shifted to healthy zones when one entire zone goes down.
|
||||
Therefore, if all nodes in a zone are unhealthy then the node controller evicts at
|
||||
Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at
|
||||
the normal rate of `--node-eviction-rate`. The corner case is when all zones are
|
||||
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
|
||||
case, the node controller assumes that there's some problem with master
|
||||
case, the node controller assumes that there is some problem with master
|
||||
connectivity and stops all evictions until some connectivity is restored.
|
||||
|
||||
The node controller is also responsible for evicting pods running on nodes with
|
||||
@@ -303,8 +306,8 @@ eligible for, effectively removing incoming load balancer traffic from the cordo
|
||||
|
||||
### Node capacity
|
||||
|
||||
Node objects track information about the Node's resource capacity (for example: the amount
|
||||
of memory available, and the number of CPUs).
|
||||
Node objects track information about the Node's resource capacity: for example, the amount
|
||||
of memory available and the number of CPUs.
|
||||
Nodes that [self register](#self-registration-of-nodes) report their capacity during
|
||||
registration. If you [manually](#manual-node-administration) add a Node, then
|
||||
you need to set the node's capacity information when you add it.
|
||||
@@ -338,7 +341,7 @@ for more information.
|
||||
If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node.
|
||||
Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.
|
||||
|
||||
When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases:
|
||||
When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown, kubelet terminates pods in two phases:
|
||||
|
||||
1. Terminate regular pods running on the node.
|
||||
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
|
||||
|
||||
@@ -43,7 +43,7 @@ Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
|
||||
fields. These fields accept key-value pairs as their values. Both the `data`
|
||||
field and the `binaryData` are optional. The `data` field is designed to
|
||||
contain UTF-8 byte sequences while the `binaryData` field is designed to
|
||||
contain binary data.
|
||||
contain binary data as base64-encoded strings.
|
||||
|
||||
The name of a ConfigMap must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
@@ -80,7 +80,7 @@ parameters:
|
||||
Users request dynamically provisioned storage by including a storage class in
|
||||
their `PersistentVolumeClaim`. Before Kubernetes v1.6, this was done via the
|
||||
`volume.beta.kubernetes.io/storage-class` annotation. However, this annotation
|
||||
is deprecated since v1.6. Users now can and should instead use the
|
||||
is deprecated since v1.9. Users now can and should instead use the
|
||||
`storageClassName` field of the `PersistentVolumeClaim` object. The value of
|
||||
this field must match the name of a `StorageClass` configured by the
|
||||
administrator (see [below](#enabling-dynamic-provisioning)).
|
||||
|
||||
@@ -34,8 +34,9 @@ Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod"
|
||||
can use any number of volume types simultaneously.
|
||||
Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
|
||||
the lifetime of a pod. Consequently, a volume outlives any containers
|
||||
that run within the pod, and data is preserved across container restarts. When a
|
||||
pod ceases to exist, the volume is destroyed.
|
||||
that run within the pod, and data is preserved across container restarts. When a pod
|
||||
ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not
|
||||
destroy persistent volumes.
|
||||
|
||||
At its core, a volume is just a directory, possibly with some data in it, which
|
||||
is accessible to the containers in a pod. How that directory comes to be, the
|
||||
|
||||
@@ -54,7 +54,7 @@ In this example:
|
||||
{{< 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".
|
||||
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 >}}
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
+172
-159
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -19,7 +19,7 @@ files by setting the KUBECONFIG environment variable or by setting the
|
||||
This overview covers `kubectl` syntax, describes the command operations, and provides common examples.
|
||||
For details about each command, including all the supported flags and subcommands, see the
|
||||
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation.
|
||||
For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
For installation instructions see [installing kubectl](/docs/tasks/tools/).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
@@ -181,8 +181,6 @@ that are not enabled by default:
|
||||
- `RequestedToCapacityRatio`: Favor nodes according to a configured function of
|
||||
the allocated resources.
|
||||
Extension points: `Score`.
|
||||
- `NodeResourceLimits`: Favors nodes that satisfy the Pod resource limits.
|
||||
Extension points: `PreScore`, `Score`.
|
||||
- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
|
||||
for the node.
|
||||
Extension points: `Filter`.
|
||||
|
||||
@@ -147,7 +147,7 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### systemd {#containerd-systemd}
|
||||
#### Using the `systemd` cgroup driver {#containerd-systemd}
|
||||
|
||||
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
|
||||
|
||||
@@ -158,6 +158,12 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`,
|
||||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
If you apply this change make sure to restart containerd again:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
When using kubeadm, manually configure the
|
||||
[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).
|
||||
|
||||
@@ -347,7 +353,7 @@ in sync.
|
||||
|
||||
### Docker
|
||||
|
||||
1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server)
|
||||
1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
|
||||
|
||||
2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ kops is an automated provisioning system:
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed.
|
||||
* You must have [kubectl](/docs/tasks/tools/) installed.
|
||||
|
||||
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
|
||||
|
||||
|
||||
@@ -160,7 +160,7 @@ kubelet and the control plane is supported, but the kubelet version may never ex
|
||||
server version. For example, the kubelet running 1.7.0 should be fully compatible with a 1.8.0 API server,
|
||||
but not vice versa.
|
||||
|
||||
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/).
|
||||
|
||||
{{< warning >}}
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
|
||||
@@ -221,7 +221,7 @@ On Windows, you can use the following settings to configure Services and load ba
|
||||
|
||||
#### IPv4/IPv6 dual-stack
|
||||
|
||||
You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the `IPv6DualStack` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/). See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details.
|
||||
You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details.
|
||||
|
||||
{{< note >}}
|
||||
On Windows, using IPv6 with Kubernetes require Windows Server, version 2004 (kernel version 10.0.19041.610) or later.
|
||||
|
||||
@@ -1906,7 +1906,7 @@ filename | sha512 hash
|
||||
- Promote SupportNodePidsLimit to GA to provide node to pod pid isolation
|
||||
Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing]
|
||||
- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
|
||||
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
|
||||
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
|
||||
- Set CSIMigrationvSphere feature gates to beta.
|
||||
Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.
|
||||
|
||||
|
||||
@@ -192,7 +192,7 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod).
|
||||
If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod).
|
||||
|
||||
#### Python client
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ If your cluster was deployed using the `kubeadm` tool, refer to
|
||||
for detailed information on how to upgrade the cluster.
|
||||
|
||||
Once you have upgraded the cluster, remember to
|
||||
[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
[install the latest version of `kubectl`](/docs/tasks/tools/).
|
||||
|
||||
### Manual deployments
|
||||
|
||||
@@ -52,7 +52,7 @@ You should manually update the control plane following this sequence:
|
||||
- cloud controller manager, if you use one
|
||||
|
||||
At this point you should
|
||||
[install the latest version of `kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
[install the latest version of `kubectl`](/docs/tasks/tools/).
|
||||
|
||||
For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/)
|
||||
that node and then either replace it with a new node that uses the {{< skew latestVersion >}}
|
||||
|
||||
@@ -170,36 +170,7 @@ controllerManager:
|
||||
|
||||
### Create certificate signing requests (CSR)
|
||||
|
||||
You can create the certificate signing requests for the Kubernetes certificates API with `kubeadm certs renew --use-api`.
|
||||
|
||||
If you set up an external signer such as [cert-manager](https://github.com/jetstack/cert-manager), certificate signing requests (CSRs) are automatically approved.
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command.
|
||||
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
|
||||
|
||||
```shell
|
||||
sudo kubeadm certs renew apiserver --use-api &
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
[1] 2890
|
||||
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
|
||||
```
|
||||
|
||||
### Approve certificate signing requests (CSR)
|
||||
|
||||
If you set up an external signer, certificate signing requests (CSRs) are automatically approved.
|
||||
|
||||
Otherwise, you must manually approve certificates with the [`kubectl certificate`](/docs/setup/best-practices/certificates/) command. e.g.
|
||||
|
||||
```shell
|
||||
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
```
|
||||
The output is similar to this:
|
||||
```shell
|
||||
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
|
||||
```
|
||||
|
||||
You can view a list of pending certificates with `kubectl get csr`.
|
||||
See [Create CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest) for creating CSRs with the Kubernetes API.
|
||||
|
||||
## Renew certificates with external CA
|
||||
|
||||
|
||||
@@ -202,4 +202,7 @@ verify that the pods were scheduled by the desired schedulers.
|
||||
```shell
|
||||
kubectl get events
|
||||
```
|
||||
You can also use a [custom scheduler configuration](/docs/reference/scheduling/config/#multiple-profiles)
|
||||
or a custom container image for the cluster's main scheduler by modifying its static pod manifest
|
||||
on the relevant control plane nodes.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ preview of what changes `apply` will make.
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ explains how those commands are organized and how to use them to manage live obj
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ This document explains how to define and manage objects using configuration file
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
|
||||
Install [`kubectl`](/docs/tasks/tools/).
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Up to date information on this process can be found at the
|
||||
* You must have a Kubernetes cluster with cluster DNS enabled.
|
||||
* If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
|
||||
* If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
|
||||
* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
|
||||
* [Install and setup kubectl](/docs/tasks/tools/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
|
||||
* Install [Helm](https://helm.sh/) v2.7.0 or newer.
|
||||
* Follow the [Helm install instructions](https://helm.sh/docs/intro/install/).
|
||||
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
|
||||
|
||||
@@ -23,7 +23,7 @@ Service Catalog itself can work with any kind of managed service, not just Googl
|
||||
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
|
||||
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
|
||||
* Service Catalog requires Kubernetes version 1.7+.
|
||||
* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
|
||||
* [Install and setup kubectl](/docs/tasks/tools/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
|
||||
* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:
|
||||
|
||||
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
|
||||
|
||||
@@ -80,10 +80,10 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
|
||||
echo 'complete -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- 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.
|
||||
- If you installed kubectl with Homebrew (as explained [here](/docs/tasks/tools/install-kubectl-macos/#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 >}}
|
||||
|
||||
In any case, after reloading your shell, kubectl completion should be working.
|
||||
In any case, after reloading your shell, kubectl completion should be working.
|
||||
|
||||
@@ -23,7 +23,7 @@ The following methods exist for installing kubectl on macOS:
|
||||
- [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos)
|
||||
- [Install with Homebrew on macOS](#install-with-homebrew-on-macos)
|
||||
- [Install with Macports on macOS](#install-with-macports-on-macos)
|
||||
- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk)
|
||||
- [Install on macOS as part of the Google Cloud SDK](#install-on-macos-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### Install kubectl binary with curl on macOS
|
||||
|
||||
@@ -157,4 +157,4 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
||||
@@ -37,7 +37,7 @@ profiles that give only the necessary privileges to your container processes.
|
||||
|
||||
In order to complete all steps in this tutorial, you must install
|
||||
[kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and
|
||||
[kubectl](/docs/tasks/tools/install-kubectl/). This tutorial will show examples
|
||||
[kubectl](/docs/tasks/tools/). This tutorial will show examples
|
||||
with both alpha (pre-v1.19) and generally available seccomp functionality, so
|
||||
make sure that your cluster is [configured
|
||||
correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
|
||||
|
||||
@@ -15,10 +15,8 @@ This page provides a real world example of how to configure Redis using a Config
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* Create a `kustomization.yaml` file containing:
|
||||
* a ConfigMap generator
|
||||
* a Pod resource config using the ConfigMap
|
||||
* Apply the directory by running `kubectl apply -k ./`
|
||||
* Create a ConfigMap with Redis configuration values
|
||||
* Create a Redis Pod that mounts and uses the created ConfigMap
|
||||
* Verify that the configuration was correctly applied.
|
||||
|
||||
|
||||
@@ -38,82 +36,218 @@ This page provides a real world example of how to configure Redis using a Config
|
||||
|
||||
## Real World Example: Configuring Redis using a ConfigMap
|
||||
|
||||
You can follow the steps below to configure a Redis cache using data stored in a ConfigMap.
|
||||
Follow the steps below to configure a Redis cache using data stored in a ConfigMap.
|
||||
|
||||
First create a `kustomization.yaml` containing a ConfigMap from the `redis-config` file:
|
||||
|
||||
{{< codenew file="pods/config/redis-config" >}}
|
||||
First create a ConfigMap with an empty configuration block:
|
||||
|
||||
```shell
|
||||
curl -OL https://k8s.io/examples/pods/config/redis-config
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-redis-config
|
||||
files:
|
||||
- redis-config
|
||||
cat <<EOF >./example-redis-config.yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: example-redis-config
|
||||
data:
|
||||
redis-config: ""
|
||||
EOF
|
||||
```
|
||||
|
||||
Add the pod resource config to the `kustomization.yaml`:
|
||||
Apply the ConfigMap created above, along with a Redis pod manifest:
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-redis-config.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
|
||||
```
|
||||
|
||||
Examine the contents of the Redis pod manifest and note the following:
|
||||
|
||||
* A volume named `config` is created by `spec.volumes[1]`
|
||||
* The `key` and `path` under `spec.volumes[1].items[0]` exposes the `redis-config` key from the
|
||||
`example-redis-config` ConfigMap as a file named `redis.conf` on the `config` volume.
|
||||
* The `config` volume is then mounted at `/redis-master` by `spec.containers[0].volumeMounts[1]`.
|
||||
|
||||
This has the net effect of exposing the data in `data.redis-config` from the `example-redis-config`
|
||||
ConfigMap above as `/redis-master/redis.conf` inside the Pod.
|
||||
|
||||
{{< codenew file="pods/config/redis-pod.yaml" >}}
|
||||
|
||||
```shell
|
||||
curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
|
||||
Examine the created objects:
|
||||
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- redis-pod.yaml
|
||||
EOF
|
||||
```shell
|
||||
kubectl get pod/redis configmap/example-redis-config
|
||||
```
|
||||
|
||||
Apply the kustomization directory to create both the ConfigMap and Pod objects:
|
||||
You should see the following output:
|
||||
|
||||
```shell
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
Examine the created objects by
|
||||
```shell
|
||||
> kubectl get -k .
|
||||
NAME DATA AGE
|
||||
configmap/example-redis-config-dgh9dg555m 1 52s
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/redis 1/1 Running 0 52s
|
||||
pod/redis 1/1 Running 0 8s
|
||||
|
||||
NAME DATA AGE
|
||||
configmap/example-redis-config 1 14s
|
||||
```
|
||||
|
||||
In the example, the config volume is mounted at `/redis-master`.
|
||||
It uses `path` to add the `redis-config` key to a file named `redis.conf`.
|
||||
The file path for the redis config, therefore, is `/redis-master/redis.conf`.
|
||||
This is where the image will look for the config file for the redis master.
|
||||
Recall that we left `redis-config` key in the `example-redis-config` ConfigMap blank:
|
||||
|
||||
Use `kubectl exec` to enter the pod and run the `redis-cli` tool to verify that
|
||||
the configuration was correctly applied:
|
||||
```shell
|
||||
kubectl describe configmap/example-redis-config
|
||||
```
|
||||
|
||||
You should see an empty `redis-config` key:
|
||||
|
||||
```shell
|
||||
Name: example-redis-config
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Data
|
||||
====
|
||||
redis-config:
|
||||
```
|
||||
|
||||
Use `kubectl exec` to enter the pod and run the `redis-cli` tool to check the current configuration:
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis -- redis-cli
|
||||
```
|
||||
|
||||
Check `maxmemory`:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory
|
||||
```
|
||||
|
||||
It should show the default value of 0:
|
||||
|
||||
```shell
|
||||
1) "maxmemory"
|
||||
2) "0"
|
||||
```
|
||||
|
||||
Similarly, check `maxmemory-policy`:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory-policy
|
||||
```
|
||||
|
||||
Which should also yield its default value of `noeviction`:
|
||||
|
||||
```shell
|
||||
1) "maxmemory-policy"
|
||||
2) "noeviction"
|
||||
```
|
||||
|
||||
Now let's add some configuration values to the `example-redis-config` ConfigMap:
|
||||
|
||||
{{< codenew file="pods/config/example-redis-config.yaml" >}}
|
||||
|
||||
Apply the updated ConfigMap:
|
||||
|
||||
```shell
|
||||
kubectl apply -f example-redis-config.yaml
|
||||
```
|
||||
|
||||
Confirm that the ConfigMap was updated:
|
||||
|
||||
```shell
|
||||
kubectl describe configmap/example-redis-config
|
||||
```
|
||||
|
||||
You should see the configuration values we just added:
|
||||
|
||||
```shell
|
||||
Name: example-redis-config
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Data
|
||||
====
|
||||
redis-config:
|
||||
----
|
||||
maxmemory 2mb
|
||||
maxmemory-policy allkeys-lru
|
||||
```
|
||||
|
||||
Check the Redis Pod again using `redis-cli` via `kubectl exec` to see if the configuration was applied:
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis -- redis-cli
|
||||
```
|
||||
|
||||
Check `maxmemory`:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory
|
||||
```
|
||||
|
||||
It remains at the default value of 0:
|
||||
|
||||
```shell
|
||||
1) "maxmemory"
|
||||
2) "0"
|
||||
```
|
||||
|
||||
Similarly, `maxmemory-policy` remains at the `noeviction` default setting:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory-policy
|
||||
```
|
||||
|
||||
Returns:
|
||||
|
||||
```shell
|
||||
1) "maxmemory-policy"
|
||||
2) "noeviction"
|
||||
```
|
||||
|
||||
The configuration values have not changed because the Pod needs to be restarted to grab updated
|
||||
values from associated ConfigMaps. Let's delete and recreate the Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod redis
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
|
||||
```
|
||||
|
||||
Now re-check the configuration values one last time:
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis -- redis-cli
|
||||
```
|
||||
|
||||
Check `maxmemory`:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory
|
||||
```
|
||||
|
||||
It should now return the updated value of 2097152:
|
||||
|
||||
```shell
|
||||
1) "maxmemory"
|
||||
2) "2097152"
|
||||
```
|
||||
|
||||
Similarly, `maxmemory-policy` has also been updated:
|
||||
|
||||
```shell
|
||||
127.0.0.1:6379> CONFIG GET maxmemory-policy
|
||||
```
|
||||
|
||||
It now reflects the desired value of `allkeys-lru`:
|
||||
|
||||
```shell
|
||||
1) "maxmemory-policy"
|
||||
2) "allkeys-lru"
|
||||
```
|
||||
|
||||
Delete the created pod:
|
||||
Clean up your work by deleting the created resources:
|
||||
|
||||
```shell
|
||||
kubectl delete pod redis
|
||||
kubectl delete pod/redis configmap/example-redis-config
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ weight: 10
|
||||
<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
|
||||
<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
|
||||
<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
|
||||
<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
|
||||
<li><i>ExternalName</i> - Maps the Service to the contents of the <code>externalName</code> field (e.g. `foo.bar.example.com`), by returning a <code>CNAME</code> record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of <code>kube-dns</code>, or CoreDNS version 0.0.8 or higher.</li>
|
||||
</ul>
|
||||
<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
|
||||
<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
|
||||
|
||||
@@ -11,7 +11,7 @@ external IP address.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* Install [kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
* Install [kubectl](/docs/tasks/tools/).
|
||||
* Use a cloud provider like Google Kubernetes Engine or Amazon Web Services to
|
||||
create a Kubernetes cluster. This tutorial creates an
|
||||
[external load balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/),
|
||||
|
||||
@@ -104,7 +104,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
|
||||
```shell
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
|
||||
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 8s
|
||||
mongo ClusterIP 10.0.0.151 <none> 27017/TCP 8s
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
Reference in New Issue
Block a user