Merge branch 'main' into main
This commit is contained in:
Victuos
@@ -122,6 +122,9 @@ To mark a Node unschedulable, run:
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
|
||||
for more details.
|
||||
|
||||
{{< note >}}
|
||||
Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate
|
||||
being run on an unschedulable Node. DaemonSets typically provide node-local services
|
||||
@@ -162,8 +165,8 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
|
||||
| Node Condition | Description |
|
||||
|----------------------|-------------|
|
||||
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size--that is, if the disk capacity is low; otherwise `False` |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory--that is, if the node memory is low; otherwise `False` |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` |
|
||||
| `PIDPressure` | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` |
|
||||
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
|
||||
{{< /table >}}
|
||||
@@ -174,7 +177,8 @@ If you use command-line tools to print details of a cordoned Node, the Condition
|
||||
cordoned nodes are marked Unschedulable in their spec.
|
||||
{{< /note >}}
|
||||
|
||||
The node condition is represented as a JSON object. For example, the following structure describes a healthy node:
|
||||
In the Kubernetes API, a node's condition is represented as part of the `.status`
|
||||
of the Node resource. For example, the following JSON structure describes a healthy node:
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
@@ -189,7 +193,17 @@ 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" >}}), 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.
|
||||
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 the [node controller](#node-controller) triggers
|
||||
{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
|
||||
for all Pods assigned to that node. 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
|
||||
@@ -199,10 +213,12 @@ may need to delete the node object by hand. Deleting the node object from Kubern
|
||||
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
|
||||
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions.
|
||||
When problems occur on nodes, the Kubernetes control plane automatically creates
|
||||
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions
|
||||
affecting the node.
|
||||
The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
|
||||
Pods can also have tolerations which let them tolerate a Node's taints.
|
||||
Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let
|
||||
them run on a Node even though it has a specific taint.
|
||||
|
||||
See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)
|
||||
for more details.
|
||||
@@ -222,10 +238,43 @@ on a Node.
|
||||
|
||||
### Info
|
||||
|
||||
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
|
||||
This information is gathered by Kubelet from the node.
|
||||
Describes general information about the node, such as kernel version, Kubernetes
|
||||
version (kubelet and kube-proxy version), container runtime details, and which
|
||||
operating system the node uses.
|
||||
The kubelet gathers this information from the node and publishes it into
|
||||
the Kubernetes API.
|
||||
|
||||
### Node controller
|
||||
## Heartbeats
|
||||
|
||||
Heartbeats, sent by Kubernetes nodes, help your cluster determine the
|
||||
availability of each node, and to take action when failures are detected.
|
||||
|
||||
For nodes there are two forms of heartbeats:
|
||||
|
||||
* updates to the `.status` of a Node
|
||||
* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) objects
|
||||
within the `kube-node-lease`
|
||||
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
|
||||
Each Node has an associated Lease object.
|
||||
|
||||
Compared to updates to `.status` of a Node, a Lease is a lightweight resource.
|
||||
Using Leases for heartbeats reduces the performance impact of these updates
|
||||
for large clusters.
|
||||
|
||||
The kubelet is responsible for creating and updating the `.status` of Nodes,
|
||||
and for updating their related Leases.
|
||||
|
||||
- The kubelet updates the node's `.status` either when there is change in status
|
||||
or if there has been no update for a configured interval. The default interval
|
||||
for `.status` updates to Nodes 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
|
||||
updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
|
||||
using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
|
||||
|
||||
|
||||
## Node controller
|
||||
|
||||
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
|
||||
Kubernetes control plane component that manages various aspects of nodes.
|
||||
@@ -241,39 +290,18 @@ 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, 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.
|
||||
- In the case that a node becomes unreachable, updating the NodeReady condition
|
||||
of within the Node's `.status`. In this case the node controller sets the
|
||||
NodeReady condition to `ConditionUnknown`.
|
||||
- If a node remains unreachable: triggering
|
||||
[API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/)
|
||||
for all of the Pods on the unreachable node. By default, the node controller
|
||||
waits 5 minutes between marking the node as `ConditionUnknown` and submitting
|
||||
the first eviction request.
|
||||
|
||||
The node controller checks the state of each node every `--node-monitor-period` seconds.
|
||||
|
||||
#### Heartbeats
|
||||
|
||||
Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
|
||||
|
||||
There are two forms of heartbeats: updates of `NodeStatus` and the
|
||||
[Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io).
|
||||
Each Node has an associated Lease object in the `kube-node-lease`
|
||||
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
|
||||
Lease is a lightweight resource, which improves the performance
|
||||
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
|
||||
or if there has been no update for a configured interval. The default interval
|
||||
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.
|
||||
|
||||
#### Reliability
|
||||
### Rate limits on eviction
|
||||
|
||||
In most cases, the node controller limits the eviction rate to
|
||||
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
@@ -281,7 +309,7 @@ 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
|
||||
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.
|
||||
@@ -293,15 +321,17 @@ the same time:
|
||||
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).
|
||||
then the eviction mechanism does not take per-zone unavailability into account.
|
||||
|
||||
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
|
||||
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 is some problem with master
|
||||
connectivity and stops all evictions until some connectivity is restored.
|
||||
completely unhealthy (none of the nodes in the cluster are healthy). In such a
|
||||
case, the node controller assumes that there is some problem with connectivity
|
||||
between the control plane and the nodes, and doesn't perform any evictions.
|
||||
(If there has been an outage and some nodes reappear, the node controller does
|
||||
evict pods from the remaining nodes that are unhealthy or unreachable).
|
||||
|
||||
The node controller is also responsible for evicting pods running on nodes with
|
||||
`NoExecute` taints, unless those pods tolerate that taint.
|
||||
@@ -309,7 +339,7 @@ The node controller also adds {{< glossary_tooltip text="taints" term_id="taint"
|
||||
corresponding to node problems like node unreachable or not ready. This means
|
||||
that the scheduler won't place Pods onto unhealthy nodes.
|
||||
|
||||
### Node capacity
|
||||
## Resource capacity tracking {#node-capacity}
|
||||
|
||||
Node objects track information about the Node's resource capacity: for example, the amount
|
||||
of memory available and the number of CPUs.
|
||||
|
||||
@@ -81,7 +81,7 @@ rotate an application's logs automatically.
|
||||
|
||||
As an example, you can find detailed information about how `kube-up.sh` sets
|
||||
up logging for COS image on GCP in the corresponding
|
||||
[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).
|
||||
[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh).
|
||||
|
||||
When using a **CRI container runtime**, the kubelet is responsible for rotating the logs and managing the logging directory structure.
|
||||
The kubelet sends this information to the CRI container runtime and the runtime writes the container logs to the given location.
|
||||
|
||||
@@ -160,7 +160,7 @@ If you're interested in learning more about `kubectl`, go ahead and read [kubect
|
||||
|
||||
The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.
|
||||
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
|
||||
@@ -21,7 +21,7 @@ This is a living document. If you think of something that is not on this list bu
|
||||
|
||||
- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
|
||||
|
||||
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
|
||||
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
|
||||
|
||||
- Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
|
||||
|
||||
@@ -63,7 +63,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
||||
|
||||
## Using Labels
|
||||
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
|
||||
|
||||
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ FOO_SERVICE_PORT=<the port the service is running on>
|
||||
```
|
||||
|
||||
Services have dedicated IP addresses and are available to the Container via DNS,
|
||||
if [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.
|
||||
if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/) is enabled.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -133,7 +133,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
|
||||
|
||||
Kubernetes supports 2 primary modes of finding a Service - environment variables
|
||||
and DNS. The former works out of the box while the latter requires the
|
||||
[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
[CoreDNS cluster addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns).
|
||||
{{< note >}}
|
||||
If the service environment variables are not desired (because possible clashing with expected program ones,
|
||||
too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
|
||||
@@ -231,7 +231,7 @@ Till now we have only accessed the nginx server from within the cluster. Before
|
||||
* An nginx server configured to use the certificates
|
||||
* A [secret](/docs/concepts/configuration/secret/) that makes the certificates accessible to pods
|
||||
|
||||
You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short:
|
||||
You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short:
|
||||
|
||||
```shell
|
||||
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
|
||||
@@ -303,7 +303,7 @@ Now modify your nginx replicas to start an https server using the certificate in
|
||||
Noteworthy points about the nginx-secure-app manifest:
|
||||
|
||||
- It contains both Deployment and Service specification in the same file.
|
||||
- The [nginx server](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
|
||||
- The [nginx server](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
|
||||
serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service
|
||||
exposes both ports.
|
||||
- Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`.
|
||||
|
||||
@@ -252,7 +252,7 @@ spec:
|
||||
endPort: 32768
|
||||
```
|
||||
|
||||
The above rule allows any Pod with label `db` on the namespace `default` to communicate
|
||||
The above rule allows any Pod with label `role=db` on the namespace `default` to communicate
|
||||
with any IP within the range `10.0.0.0/24` over TCP, provided that the target
|
||||
port is between the range 32000 and 32768.
|
||||
|
||||
|
||||
@@ -428,8 +428,7 @@ variables and DNS.
|
||||
|
||||
When a Pod is run on a Node, the kubelet adds a set of environment variables
|
||||
for each active Service. It supports both [Docker links
|
||||
compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
|
||||
[makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72))
|
||||
compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/envvars/envvars.go#L72))
|
||||
and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
|
||||
where the Service name is upper-cased and dashes are converted to underscores.
|
||||
|
||||
|
||||
@@ -130,7 +130,7 @@ and the kubelet, set the `InTreePluginAWSUnregister` flag to `true`.
|
||||
|
||||
The `azureDisk` volume type mounts a Microsoft Azure [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) into a pod.
|
||||
|
||||
For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md).
|
||||
For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md).
|
||||
|
||||
#### azureDisk CSI migration
|
||||
|
||||
@@ -148,7 +148,7 @@ features must be enabled.
|
||||
The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0)
|
||||
into a pod.
|
||||
|
||||
For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md).
|
||||
For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md).
|
||||
|
||||
#### azureFile CSI migration
|
||||
|
||||
@@ -176,7 +176,7 @@ writers simultaneously.
|
||||
You must have your own Ceph server running with the share exported before you can use it.
|
||||
{{< /note >}}
|
||||
|
||||
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details.
|
||||
See the [CephFS example](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) for more details.
|
||||
|
||||
### cinder
|
||||
|
||||
@@ -347,7 +347,7 @@ You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to th
|
||||
beforehand so that Kubernetes hosts can access them.
|
||||
{{< /note >}}
|
||||
|
||||
See the [fibre channel example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
|
||||
See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details.
|
||||
|
||||
### flocker (deprecated) {#flocker}
|
||||
|
||||
@@ -365,7 +365,7 @@ can be shared between pods as required.
|
||||
You must have your own Flocker installation running before you can use it.
|
||||
{{< /note >}}
|
||||
|
||||
See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details.
|
||||
See the [Flocker example](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) for more details.
|
||||
|
||||
### gcePersistentDisk
|
||||
|
||||
@@ -533,7 +533,7 @@ simultaneously.
|
||||
You must have your own GlusterFS installation running before you can use it.
|
||||
{{< /note >}}
|
||||
|
||||
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details.
|
||||
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) for more details.
|
||||
|
||||
### hostPath {#hostpath}
|
||||
|
||||
@@ -661,7 +661,7 @@ and then serve it in parallel from as many Pods as you need. Unfortunately,
|
||||
iSCSI volumes can only be mounted by a single consumer in read-write mode.
|
||||
Simultaneous writers are not allowed.
|
||||
|
||||
See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details.
|
||||
See the [iSCSI example](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) for more details.
|
||||
|
||||
### local
|
||||
|
||||
@@ -749,7 +749,7 @@ writers simultaneously.
|
||||
You must have your own NFS server running with the share exported before you can use it.
|
||||
{{< /note >}}
|
||||
|
||||
See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details.
|
||||
See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) for more details.
|
||||
|
||||
### persistentVolumeClaim {#persistentvolumeclaim}
|
||||
|
||||
@@ -797,7 +797,7 @@ Make sure you have an existing PortworxVolume with name `pxvol`
|
||||
before using it in the Pod.
|
||||
{{< /note >}}
|
||||
|
||||
For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) examples.
|
||||
For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) examples.
|
||||
|
||||
### projected
|
||||
|
||||
@@ -811,7 +811,7 @@ Currently, the following types of volume sources can be projected:
|
||||
* `serviceAccountToken`
|
||||
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
|
||||
|
||||
#### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
@@ -972,7 +972,7 @@ and then serve it in parallel from as many pods as you need. Unfortunately,
|
||||
RBD volumes can only be mounted by a single consumer in read-write mode.
|
||||
Simultaneous writers are not allowed.
|
||||
|
||||
See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)
|
||||
See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd)
|
||||
for more details.
|
||||
|
||||
### secret
|
||||
|
||||
@@ -632,7 +632,7 @@ of custom controller for those Pods. This allows the most flexibility, but may
|
||||
complicated to get started with and offers less integration with Kubernetes.
|
||||
|
||||
One example of this pattern would be a Job which starts a Pod which runs a script that in turn
|
||||
starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark
|
||||
starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), runs a spark
|
||||
driver, and then cleans up.
|
||||
|
||||
An advantage of this approach is that the overall process gets the completion guarantee of a Job
|
||||
|
||||
@@ -39,7 +39,7 @@ that provides a set of stateless replicas.
|
||||
|
||||
## Limitations
|
||||
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
|
||||
* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
|
||||
* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
|
||||
* StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion.
|
||||
|
||||
@@ -127,7 +127,7 @@ up the verbosity:
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
```
|
||||
|
||||
[Complete file example](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
[Complete file example](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
|
||||
## A quick note on service accounts
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ controller on the controller manager.
|
||||
|
||||
Each valid token is backed by a secret in the `kube-system` namespace. You can
|
||||
find the full design doc
|
||||
[here](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
[here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||||
|
||||
Here is what the secret looks like.
|
||||
|
||||
|
||||
@@ -165,8 +165,8 @@ different Kubernetes components.
|
||||
| `PreferNominatedNode` | `true` | Beta | 1.22 | |
|
||||
| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `ProbeTerminationGracePeriod` | `false` | Beta | 1.22 | |
|
||||
| `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
|
||||
| `ProcMountType` | `false` | Alpha | 1.12 | |
|
||||
| `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
|
||||
| `QOSReserved` | `false` | Alpha | 1.11 | |
|
||||
| `ReadWriteOncePod` | `false` | Alpha | 1.22 | |
|
||||
| `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 |
|
||||
@@ -789,10 +789,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
and volume controllers.
|
||||
- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
|
||||
controller to manage Pod completions per completion index.
|
||||
- `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job)
|
||||
completions without relying on Pods remaining in the cluster indefinitely.
|
||||
The Job controller uses Pod finalizers and a field in the Job status to keep
|
||||
track of the finished Pods to count towards completion.
|
||||
- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
|
||||
`IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
|
||||
to `IngressClass.spec.parameters`.
|
||||
@@ -800,10 +796,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
Initializers admission plugin.
|
||||
- `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/)
|
||||
support for IPv6.
|
||||
- `JobTrackingWithFinalizers`: Enables the tracking of Job completion without
|
||||
relying on Pods remaining in the cluster indefinitely. Pod finalizers, in
|
||||
addition to a field in the Job status, allow the Job controller to track
|
||||
Pods that it didn't account for yet.
|
||||
- `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job)
|
||||
completions without relying on Pods remaining in the cluster indefinitely.
|
||||
The Job controller uses Pod finalizers and a field in the Job status to keep
|
||||
track of the finished Pods to count towards completion.
|
||||
- `KubeletConfigFile`: Enable loading kubelet configuration from
|
||||
a file specified using a config file.
|
||||
See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
@@ -1012,18 +1008,16 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `WatchBookmark`: Enable support for watch bookmark events.
|
||||
- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
|
||||
- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
|
||||
- `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows
|
||||
will use EndpointSlices as the primary data source instead of Endpoints,
|
||||
enabling scalability and performance improvements. See
|
||||
[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
|
||||
- `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes.
|
||||
- `WindowsHostProcessContainers`: Enables support for Windows HostProcess containers.
|
||||
- `WindowsRunAsUserName` : Enable support for running applications in Windows containers
|
||||
with as a non-default user. See
|
||||
[Configuring RunAsUserName](/docs/tasks/configure-pod-container/configure-runasusername)
|
||||
for more details.
|
||||
- `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows
|
||||
will use EndpointSlices as the primary data source instead of Endpoints,
|
||||
enabling scalability and performance improvements. See
|
||||
[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
|
||||
- `WindowsHostProcessContainers`: Enables the support for `HostProcess`
|
||||
containers on Windows nodes.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -55,7 +55,7 @@ You can access Dashboard using the kubectl command-line tool by running the foll
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/).
|
||||
Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:https/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:https/proxy/).
|
||||
|
||||
The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Check the location and credentials that kubectl knows about with this command:
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
Many of the [examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) provide an introduction to using
|
||||
Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using
|
||||
kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
|
||||
|
||||
### Directly accessing the REST API
|
||||
|
||||
@@ -66,7 +66,8 @@ The flag takes a comma-separated list of `key=value` policy options.
|
||||
The `none` policy explicitly enables the existing default CPU
|
||||
affinity scheme, providing no affinity beyond what the OS scheduler does
|
||||
automatically. Limits on CPU usage for
|
||||
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) and
|
||||
[Burstable pods](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
are enforced using CFS quota.
|
||||
|
||||
### Static policy
|
||||
|
||||
@@ -28,7 +28,7 @@ explains how to use `kubeadm` to migrate from `kube-dns`.
|
||||
|
||||
DNS is a built-in Kubernetes service launched automatically
|
||||
using the _addon manager_
|
||||
[cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md).
|
||||
[cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md).
|
||||
|
||||
As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster
|
||||
originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS.
|
||||
|
||||
@@ -314,7 +314,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
|
||||
* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
|
||||
* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
|
||||
* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md).
|
||||
* See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md).
|
||||
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -145,7 +145,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
|
||||
other code indicates failure.
|
||||
|
||||
You can see the source code for the server in
|
||||
[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
|
||||
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
|
||||
|
||||
For the first 10 seconds that the container is alive, the `/healthz` handler
|
||||
returns a status of 200. After that, the handler returns a status of 500.
|
||||
|
||||
@@ -83,5 +83,5 @@ kubectl delete secret user pass
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
|
||||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ rules:
|
||||
```
|
||||
|
||||
If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
|
||||
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
|
||||
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
|
||||
script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script.
|
||||
|
||||
You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
|
||||
|
||||
@@ -18,7 +18,7 @@ learn how to run multiple schedulers in Kubernetes with an example.
|
||||
|
||||
A detailed description of how to implement a scheduler is outside the scope of this
|
||||
document. Please refer to the kube-scheduler implementation in
|
||||
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
|
||||
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)
|
||||
in the Kubernetes source directory for a canonical example.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
+1
-1
@@ -202,7 +202,7 @@ spec:
|
||||
plural: crontabs
|
||||
# singular name to be used as an alias on the CLI and for display
|
||||
singular: crontab
|
||||
# kind is normally the CamelCased singular type. Your resource manifests use this.
|
||||
# kind is normally the PascalCased singular type. Your resource manifests use this.
|
||||
kind: CronTab
|
||||
# shortNames allow shorter string to match your resource on the CLI
|
||||
shortNames:
|
||||
|
||||
@@ -26,7 +26,7 @@ following Kubernetes concepts:
|
||||
* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
|
||||
* [Headless Services](/docs/concepts/services-networking/service/#headless-services)
|
||||
* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
|
||||
* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* The [kubectl](/docs/reference/kubectl/kubectl/) command line tool
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Kubernetes concepts:
|
||||
- [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
|
||||
- [Headless Services](/docs/concepts/services-networking/service/#headless-services)
|
||||
- [PersistentVolumes](/docs/concepts/storage/volumes/)
|
||||
- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
|
||||
- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
|
||||
- [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
|
||||
- [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
|
||||
|
||||
Reference in New Issue
Block a user