diff --git a/OWNERS b/OWNERS index 9b12305b4b..8e4e14f60c 100644 --- a/OWNERS +++ b/OWNERS @@ -8,7 +8,9 @@ approvers: emeritus_approvers: # - chenopis, commented out to disable PR assignments +# - irvifa, commented out to disable PR assignments # - jaredbhatti, commented out to disable PR assignments +# - kbarnard10, commented out to disable PR assignments # - steveperry-53, commented out to disable PR assignments - stewart-yu # - zacharysarah, commented out to disable PR assignments diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index ea9761f277..ab0771933c 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -1,10 +1,8 @@ aliases: sig-docs-blog-owners: # Approvers for blog content - - kbarnard10 - onlydole - mrbobbytables sig-docs-blog-reviewers: # Reviewers for blog content - - kbarnard10 - mrbobbytables - onlydole - sftim @@ -20,9 +18,7 @@ aliases: - annajung - bradtopol - celestehorgan - - irvifa - jimangel - - kbarnard10 - kbhawkey - onlydole - pi-victor @@ -35,7 +31,6 @@ aliases: - celestehorgan - daminisatya - jimangel - - kbarnard10 - kbhawkey - onlydole - rajeshdeshpande02 @@ -88,7 +83,6 @@ aliases: - danninov - girikuncoro - habibrosyad - - irvifa - phanama - wahyuoi sig-docs-id-reviews: # PR reviews for Indonesian content @@ -96,7 +90,6 @@ aliases: - danninov - girikuncoro - habibrosyad - - irvifa - phanama - wahyuoi sig-docs-it-owners: # Admins for Italian content @@ -138,9 +131,7 @@ aliases: - yoonian - ysyukr sig-docs-leads: # Website chairs and tech leads - - irvifa - jimangel - - kbarnard10 - kbhawkey - onlydole - sftim diff --git a/README-pl.md b/README-pl.md index ae25b89286..06bde04303 100644 --- a/README-pl.md +++ b/README-pl.md @@ -18,7 +18,7 @@ Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować: - [npm](https://www.npmjs.com/) - [Go](https://golang.org/) - [Hugo (Extended version)](https://gohugo.io/) -- Środowisko obsługi kontenerów, np. [Docker-a](https://www.docker.com/). +- Środowisko obsługi kontenerów, np. [Dockera](https://www.docker.com/). Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu: @@ -43,7 +43,9 @@ make container-image make container-serve ``` -Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. +Jeśli widzisz błędy, prawdopodobnie kontener z Hugo nie dysponuje wystarczającymi zasobami. Aby rozwiązać ten problem, zwiększ ilość dostępnych zasobów CPU i pamięci dla Dockera na Twojej maszynie ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) i [Windows](https://docs.docker.com/docker-for-windows/#resources)). + +Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. ## Jak uruchomić lokalną kopię strony przy pomocy Hugo? diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS index 5b0cc85b45..64a1ca5415 100644 --- a/SECURITY_CONTACTS +++ b/SECURITY_CONTACTS @@ -10,7 +10,5 @@ # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ -irvifa jimangel -kbarnard10 sftim \ No newline at end of file diff --git a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 7a5fe0ce4f..4b7d5ddaae 100644 --- a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 8c74aafd78..b8eae305f3 100644 --- a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html index f220ff5eb7..5e64134a44 100644 --- a/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index ab5b880397..5b4c1a4ae8 100644 --- a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 07e76654a4..ce0f9caaae 100644 --- a/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html index 448ddc81b9..086b90d6b7 100644 --- a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html index 61ee05d662..74e3e40982 100644 --- a/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md index 7b05c1f74c..896f2c5f84 100644 --- a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md +++ b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md @@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can -Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).  +Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).  diff --git a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md index 515a3aa195..6ce3bf0044 100644 --- a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md @@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance [ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below. **Creating a ZooKeeper Ensemble** -Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest. +Creating an ensemble is as simple as using [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) to generate the objects stored in the manifest. ``` @@ -297,7 +297,7 @@ zk-0 0/1 Terminating 0 15m -You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. +You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 618f8cd76a..1d4f6455b7 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -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. diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 406420f5bf..1bf057f23e 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -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. diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index 173c3f8c15..4d98cf820c 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -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: diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 25cfb2e7f1..2f5302b4ff 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -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/). diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index a1eba4d96d..3c4c153927 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -52,7 +52,7 @@ FOO_SERVICE_PORT= ``` 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.  diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 14bc98101f..89d2daddb2 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -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`. diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index d415b836f2..e3f3a203b7 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -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. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index d501ffe309..dff13690ba 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -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. diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index d1137286be..56694dee66 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -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 diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 6d90ce1cbb..1635caf7b3 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -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 diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index faf244b1a5..1383d5410a 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -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. diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md index 3e2aea6b36..197901a170 100644 --- a/content/en/docs/reference/access-authn-authz/abac.md +++ b/content/en/docs/reference/access-authn-authz/abac.md @@ -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 diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md index f128c14a7a..7e743be63d 100644 --- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -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. diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 4e4f034ce4..d639029659 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -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" %}} diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 5c402e0304..c0413275b0 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -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. diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md index 0275cadabf..827cb50f7c 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 3a82cf9be1..9eb7d7febb 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md index 308b066651..bd2fb3684c 100644 --- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -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. diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index 0964033079..231de37e26 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -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). diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 301d81870c..d9ab2056da 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -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. diff --git a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index ad99a05c27..ca71e7a721 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -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. diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index c44caf66b5..6c4b433ca2 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -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) diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index 7ad7072fd7..d44e6897b0 100644 --- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -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" %}} diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 05e60449c4..45f589e9d7 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -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: diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md index f2d02dce11..760d3df013 100644 --- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md @@ -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 diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md index 2844ae6a0e..3ed1cd454b 100644 --- a/content/en/docs/tutorials/stateful-application/zookeeper.md +++ b/content/en/docs/tutorials/stateful-application/zookeeper.md @@ -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) diff --git a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index a91e00f679..6743729d49 100644 --- a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 28a2f35a0e..2ec6de59e9 100644 --- a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/fr/docs/concepts/workloads/_index.md b/content/fr/docs/concepts/workloads/_index.md index 1d81794f7b..4561edb155 100644 --- a/content/fr/docs/concepts/workloads/_index.md +++ b/content/fr/docs/concepts/workloads/_index.md @@ -1,4 +1,51 @@ --- title: Workloads weight: 50 +description: > + Comprendre les Pods, le plus petit objet déployable sur Kubernetes, et les abstractions de haut niveaux vous permettant de les lancer. +no_list: true --- + + + + +Un workload (charge de travail) est une application fonctionnant sur Kubernetes. Que votre workload soit un composant unique ou un agrégat de composants, sur Kubernetes celui-ci fonctionnera dans une série de pods. Dans Kubernetes, un Pod represente un ensemble de conteneur (containers) en fonctionnement sur votre cluster. + +Les pods Kubernetes ont un cycle de vie définit (defined lifecycle). Par exemple, quand un pod est en fonction sur votre cluster et qu’une panne critique survient sur le noeud (node) où se situe ce pod, tous les pods du noeud seront en échec. Kubernetes traite ce niveau d’échec comme un état final : +Vous devez créer un nouveau Pod pour retrouver l’état initial même si le noeud redevient sain. + +Cependant, pour vous simplifier la vie, vous n’avez pas a gérer chaque Pod directement. Vous pouvez utiliser une ressource workload qui gère votre groupe de pods à votre place. Ces ressources configurent des controleurs (controllers) qui s’assurent que le bon nombre et le bon type de pod soit en fonction pour égaler l’état que vous avez spécifié. + +Kubernetes fournit plusieurs ressources workload pré-faites : + +* [`Deployment`](/docs/concepts/workloads/controllers/deployment/) et [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) +(qui remplacent l’ancienne ressource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}})). +Le `Deployment` (déploiement) est une bonne approche pour manager une application stateless sur votre cluster, tous les `Pods` d’un `Deployment` sont interchangeables et peuvent être remplacés si besoin. +* Le [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) vous permet de lancer un ou plusieurs Pods en relation qui garde plus ou moins la trace de leurs état. +Par exemple si votre workload enregistre des données de façon persistente, vous pouvez lancer un `StatefulSet` qui fera le lien entre les `Pods` et un volume persistent ([`PersistentVolume`](/docs/concepts/storage/persistent-volumes/)). +Votre code, présent dans les `Pods` du `StatefulSet`, peut répliquer des données dans les autres `Pods` qui sont dans le même `StatefulSet`, +pour améliorer la résilience global. +* Le [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) permet de définir les `Pods` qui effectuent des actions sur le noeud local. +Ceux-ci peuvent être fondamental aux opérations de votre cluster, comme un outil d’aide réseau, ou peuvent faire part d’un module complémentaire (add-on). +Pour chaque nouveau noeud ajouté au cluster, le controle plane organise l'ajout d'un `Pod` pour ce `DaemonSet` sur le nouveau noeud. +* Les [`Job`](/docs/concepts/workloads/controllers/job/) et [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) sont des taches lancées jusqu’à accomplissement puis s’arrêtent. Les `Jobs` réprésentent une tâche ponctuelle, les `CronJob` sont des tâches récurrentes planifiés. + +Dans l’écosystème étendu de Kubernetes, vous pouvez trouver des ressources workload de fournisseurs tiers qui offrent des fonctionnalités supplémentaires. +L’utilisation d’un [`CustomResourceDefinition`](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) permet d’ajouter une ressource workload d’un fournisseur tiers si vous souhaitez rajouter une fonctionnalité ou un comportement spécifique qui ne fait pas partie du noyau de Kubernetes. +Par exemple, si vous voulez lancer un groupe de `Pods` pour votre application mais que vous devez arrêter leurs fonctionnement tant qu’ils ne sont pas tous disponibles, alors vous pouvez implémenter ou installer une extension qui permet cette fonctionnalité. + +## {{% heading "whatsnext" %}} +Vous pouvez continuer la lecture des ressources, vous pouvez aussi apprendre à connaitre les taches qui leurs sont liées : +* Lancer une [application stateless en utilisant un `Deployment`](/docs/tasks/run-application/run-stateless-application-deployment/). +* Lancer une application statefull, soit comme [instance unique](/docs/tasks/run-application/run-single-instance-stateful-application/) + ou alors comme un [ensemble répliqué](/docs/tasks/run-application/run-replicated-stateful-application/). +* Lancer une [tâche automatisée avec un `CronJob`](/docs/tasks/job/automated-tasks-with-cron-jobs/). + +Pour en apprendre plus sur les méchanismes de Kubernetes, de séparation du code et de la configuration, +allez voir [Configuration](/docs/concepts/configuration/). + +Il y a deux concepts supportés qui fournissent un contexte sur le sujet : comment Kubernetes gère les pods pour les applications : +* Le [ramasse-miettes](/docs/concepts/workloads/controllers/garbage-collection/), fait le ménage dans votre cluster après qu’une de _vos ressource_ soit supprimé. +* Le [temps de vie d’un controlleur éteint](/docs/concepts/workloads/controllers/ttlafterfinished/) supprime les Jobs une fois qu’un temps définit soit passé après son accomplissement. + +Une fois que votre application est lancée, vous souhaitez peut etre la rendre disponible sur internet comme un [Service](/docs/concepts/services-networking/service/) ou comme une application web uniquement en utilsant un [Ingress](/docs/concepts/services-networking/ingress). diff --git a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md index 9e00fb57b0..cdb91bb27a 100644 --- a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -135,7 +135,6 @@ hack/update-generated-swagger-docs.sh hack/update-swagger-spec.sh hack/update-openapi-spec.sh hack/update-generated-protobuf.sh -hack/update-api-reference-docs.sh ``` Exécutez `git status` pour voir ce qui a été généré. @@ -144,8 +143,6 @@ Exécutez `git status` pour voir ce qui a été généré. On branch master ... modified: api/openapi-spec/swagger.json - modified: api/swagger-spec/apps_v1.json - modified: docs/api-reference/apps/v1/definitions.html modified: staging/src/k8s.io/api/apps/v1/generated.proto modified: staging/src/k8s.io/api/apps/v1/types.go modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go diff --git a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md index eea6e5cd3d..114bcc784b 100644 --- a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -19,7 +19,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex ## Répertorier toutes les images de conteneurs dans tous les namespaces - Récupérez tous les pods dans tous les namespace à l'aide de `kubectl get pods --all-namespaces` -- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={..image}`. +- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={.items[*].spec.containers[*].image}`. Cela analysera récursivement le champ `image` du json retourné. - Voir la [reference jsonpath](/docs/reference/kubectl/jsonpath/) pour plus d'informations sur l'utilisation de jsonpath. - Formatez la sortie à l'aide des outils standard: `tr`, `sort`, `uniq` @@ -28,7 +28,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex - Utilisez `uniq` pour agréger le nombre d'images ```shell -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -69,7 +69,7 @@ Pour cibler uniquement les pods correspondant à un label spécifique, utilisez Les éléments suivants correspondent uniquement aux pods avec les labels `app=nginx`. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## Filtrage des images de conteneur de liste par namespace de pod @@ -78,7 +78,7 @@ Pour cibler uniquement les pods dans un namespace spécifique, utilisez l'indica Ce qui suit correspond uniquement aux pods du namespace `kube-system`. ```shell -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## Répertorier les images de conteneurs en utilisant un go-template au lieu de jsonpath diff --git a/content/hi/docs/_index.md b/content/hi/docs/_index.md new file mode 100644 index 0000000000..2244c2f26b --- /dev/null +++ b/content/hi/docs/_index.md @@ -0,0 +1,6 @@ +--- +linktitle: कुबेरनेट्स प्रलेखन +title: प्रलेखन +sitemap: + priority: 1.0 +--- diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md index f2140e5276..86a6b267e2 100644 --- a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -28,7 +28,7 @@ Container untuk masing-masing Pod. - Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces` - Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container - dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_ + dengan menggunakan perintah `-o jsonpath={.items[*].spec.containers[*].image}`. Perintah ini akan mem-_parsing field_ `image` dari keluaran json yang dihasilkan. - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/) untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`. @@ -38,7 +38,7 @@ Container untuk masing-masing Pod. - Gunakan `uniq` untuk mengumpulkan jumlah _image_ ```sh -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -86,7 +86,7 @@ Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`. ```sh -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod @@ -95,7 +95,7 @@ Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. dibawah ini hanya menyaring Pod pada Namespace `kube-system`. ```sh -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 570134b84d..89e927aff9 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -47,7 +47,7 @@ Podをスケジュールできない理由に関するスケジューラーか クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。 この場合、いくつかのことを試すことができます。 -* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 +* クラスターにノードを追加します。 * [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index ccd3ee9290..3084651390 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -105,9 +105,9 @@ CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. -`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 로 변환되며, -`1m` 도 허용되지 않게 정밀하다. 이러한 이유로, `100m` 형식이 -선호될 수 있다. +`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, +`1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로, +`100m` 과 같은 형식이 선호될 수 있다. CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. 0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index b4cc1b3be5..90d151e768 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -77,7 +77,7 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, 힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. {{< /note >}} -자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. +자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다. diff --git a/content/pl/_index.html b/content/pl/_index.html index 1096114700..03ec4a4c44 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -44,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr

- Weź udział w wirtualnym KubeCon NA, 17-20.11.2020 + Weź udział w KubeCon North America 11-15.10.2021



- Weź udział w wirtualnym KubeCon EU 4–7.05.2021 + Weź udział w wirtualnym KubeCon Europe 17-20.5.2022
diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md index dba2d1e782..b6843e04db 100644 --- a/content/pl/docs/concepts/overview/components.md +++ b/content/pl/docs/concepts/overview/components.md @@ -27,7 +27,7 @@ Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego r Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik). -Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*. +Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach wirtualnych. ### kube-apiserver @@ -45,10 +45,11 @@ Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klas {{< glossary_definition term_id="kube-controller-manager" length="all" >}} -Kontrolerami są: +Przykładowe kontrolery: * Node controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny. -* Replication controller: Odpowiada za utrzymanie prawidłowej liczby podów dla każdego obiektu typu *ReplicationController* w systemie. +* Job controller: Czeka na obiekty typu *Job*, które definiują zadania uruchamiane jednorazowo + i startuje Pody, odpowiadające za ich wykonanie tych zadań. * Endpoints controller: Dostarcza informacji do obiektów typu *Endpoints* (tzn. łączy ze sobą Serwisy i Pody). * Service Account & Token controllers: Tworzy domyślne konta i tokeny dostępu API dla nowych przestrzeni nazw (*namespaces*). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index d28c841553..7391ed6602 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -14,11 +14,10 @@ sitemap: Na tej stronie znajdziesz ogólne informacje o Kubernetesie. - Kubernetes to przenośna, rozszerzalna platforma oprogramowania *open-source* służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach, która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija. Serwisy Kubernetesa, wsparcie i narzędzia są szeroko dostępne. -Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. +Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s" .Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. ## Trochę historii diff --git a/content/pl/docs/reference/tools.md b/content/pl/docs/reference/tools.md deleted file mode 100644 index 2ec66964ed..0000000000 --- a/content/pl/docs/reference/tools.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Narzędzia -content_type: concept ---- - - -Kubernetes zawiera różne wbudowane narzędzia służące do pracy z systemem: - - - -## Kubectl - -[`kubectl`](/docs/tasks/tools/install-kubectl/) to narzędzie tekstowe (linii poleceń) do Kubernetes. Służy do zarządzania klastrem Kubernetes. - -## Kubeadm - -[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) to narzędzie tekstowe do łatwej instalacji klastra Kubernetes w bezpiecznej konfiguracji, uruchamianego na infrastrukturze serwerów fizycznych, serwerów w chmurze bądź na maszynach wirtualnych (aktualnie w fazie rozwojowej alfa). - -## Minikube - -[`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do uruchamiania jednowęzłowego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów. - -## Pulpit *(Dashboard)* - -[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/) - graficzny interfejs użytkownika w przeglądarce web, który umożliwia instalację aplikacji w kontenerach na klastrze Kubernetes, rozwiązywanie problemów z nimi związanych oraz zarządzanie samym klastrem i jego zasobami. - -## Helm - -[`Kubernetes Helm`](https://github.com/kubernetes/helm) — narzędzie do zarządzania pakietami wstępnie skonfigurowanych zasobów Kubernetes (nazywanych *Kubernetes charts*). - -Helm-a można używać do: - -* Wyszukiwania i instalowania popularnego oprogramowania dystrybuowanego jako Kubernetes *charts* -* Udostępniania własnych aplikacji w postaci pakietów Kubernetes *charts* -* Definiowania powtarzalnych instalacji aplikacji na Kubernetes -* Inteligentnego zarządzania plikami list (*manifests*) Kubernetes -* Zarządzaniem kolejnymi wydaniami pakietów Helm - -## Kompose - -[`Kompose`](https://github.com/kubernetes/kompose) to narzędzie, które ma pomóc użytkownikom Docker Compose przenieść się na Kubernetes. - -Kompose można używać do: - -* Tłumaczenia plików Docker Compose na obiekty Kubernetes -* Zmiany sposóbu zarządzania twoimi aplikacjami z lokalnego środowiska Docker na system Kubernetes -* Zamiany plików `yaml` Docker Compose v1 lub v2 oraz [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) - diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index 6107fe0f03..a2908369f7 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -1,9 +1,9 @@ --- -no_issue: true title: Od czego zacząć main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 @@ -19,16 +19,44 @@ card: Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa. Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem. -Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym albo skorzystać z klastra Kubernetes udostępnianego jako usługa. Inną możliwością jest budowa własnego systemu opartego o różnych dostawców usług chmurowych, bądź bazującego bezpośrednio na sprzęcie fizycznym. +Możesz [pobrać Kubernetesa](/releases/download/), aby zainstalować klaster +na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym. + +Jeśli nie chcesz zarządzać klastrem Kubernetesa samodzielnie, możesz wybrać serwis zarządzany przez zewnętrznego dostawcę, +wybierając na przykład spośród [certyfikowanych platform](/docs/setup/production-environment/turnkey-solutions/). +Dostępne są także inne standardowe i specjalizowane rozwiązania dla różnych środowisk chmurowych +bądź bazujące bezpośrednio na sprzęcie fizycznym. ## Środowisko do nauki {#srodowisko-do-nauki} -Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. +Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa +lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. +Zapoznaj się z [narzędziami instalacyjnymi](/docs/tasks/tools/). ## Środowisko produkcyjne {#srodowisko-produkcyjne} -Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora. +Wybierając rozwiązanie dla +[środowiska produkcyjnego](/docs/setup/production-environment/) musisz zdecydować, +którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, +a które będą realizowane po stronie zewnętrznego operatora. -Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). +Do instalacji klastra Kubernetesa zarządzanego samodzielnie oficjalnym narzędziem +jest [kubeadm](/docs/setup/production-environment/tools/kubeadm/). + +## {{% heading "whatsnext" %}} + +- [Pobierz Kubernetesa](/releases/download/) +- Pobierz i [zainstaluj narzędzia](/docs/tasks/tools/), w tym `kubectl` +- Wybierz [środowisko uruchomieniowe dla kontenerów](/docs/setup/production-environment/container-runtimes/) w nowym klastrze +- Naucz się [najlepszych praktyk](/docs/setup/best-practices/) przy konfigurowaniu klastra + +Na stronie [Partnerów Kubernetesa](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających +[certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). + +Kubernetes zaprojektowano w ten sposób, że {{< glossary_tooltip term_id="control-plane" text="warstwa sterowania" >}} +wymaga do działania systemu Linux. W ramach klastra aplikacje mogą być uruchamiane na systemie Linux i innych, +w tym Windows. + +- Naucz się, [jak zbudować klaster z węzłami Windows](/docs/setup/production-environment/windows/) diff --git a/content/pl/docs/setup/release/_index.md b/content/pl/docs/setup/release/_index.md deleted file mode 100644 index 2783105198..0000000000 --- a/content/pl/docs/setup/release/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "Informacje o wydaniach i dozwolonych różnicach wersji" -weight: 10 ---- diff --git a/content/pl/docs/tutorials/kubernetes-basics/_index.html b/content/pl/docs/tutorials/kubernetes-basics/_index.html index e27a3ad6bf..0996edc64b 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/_index.html +++ b/content/pl/docs/tutorials/kubernetes-basics/_index.html @@ -11,7 +11,7 @@ card: - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 12211e42b6..72409e9238 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 3955e557c4..c5eddaf5f9 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 64c1a0a9a1..954bad22b3 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index c879aa82b9..f4b893d60b 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index 1ae1e88382..14afae5a3d 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html index edfff527e6..f62563e1cd 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index a1aca99ce3..1aefa3e793 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html index f9f9134e4a..199ab9dfe7 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index e8017f5ad6..7990fbd1a6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 91eb10eb6d..bb2c40ffee 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html index 07731b5849..5664abc0e6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html index b51779237d..2c42eee6d6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/releases/_index.md b/content/pl/releases/_index.md index 5df8f36264..46c2a7659f 100644 --- a/content/pl/releases/_index.md +++ b/content/pl/releases/_index.md @@ -24,4 +24,4 @@ Więcej informacji można z znaleźć w dokumencie [version skew policy](/releas Zajrzyj na [harmonogram](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) nadchodzącego wydania Kubernetesa numer **{{< skew nextMinorVersion >}}**! -## Przydatne zasoby \ No newline at end of file +## Przydatne zasoby diff --git a/content/vi/docs/tutorials/kubernetes-basics/_index.html b/content/vi/docs/tutorials/kubernetes-basics/_index.html index 2440ca5e67..30e370294f 100644 --- a/content/vi/docs/tutorials/kubernetes-basics/_index.html +++ b/content/vi/docs/tutorials/kubernetes-basics/_index.html @@ -10,7 +10,7 @@ card: - + diff --git a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 76fd8004ee..4c2ea13af3 100644 --- a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 9fc822147c..c5d8e13ad9 100644 --- a/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/vi/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index 2a8d45f170..8169a3b989 100644 --- a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-intro.html index fbde8b0797..7a27af279a 100644 --- a/content/vi/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/vi/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 2dd14158f0..738ba23e06 100644 --- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -78,12 +78,14 @@ If your extension API server cannot achieve that latency requirement, consider m * 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， 了解如何在自己的环境中启用聚合器。 * 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， 开始使用聚合层。 -* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 -* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范 +* 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。 + +或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index 7f93a31186..ca16706ff2 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -579,7 +579,7 @@ must be satisfied for the pod to be scheduled onto a node. --> #### 名字空间选择算符 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} -此功能特性是 Alpha 版本的，默认是被禁用的。你可以通过针对 kube-apiserver 和 +此功能特性是 Beta 版本的，默认是被启用的。你可以通过针对 kube-apiserver 和 kube-scheduler 设置 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -`PodAffinityNamespaceSelector` 来启用此特性。 +`PodAffinityNamespaceSelector` 来禁用此特性。 - - - -本页提供 Kubernetes 驱逐策略的概览。 - - - - -## 驱逐策略 {#eviction-policy} - -{{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} 主动监测和防止 -计算资源的全面短缺。在资源短缺时，`kubelet` 可以主动地结束一个或多个 Pod -以回收短缺的资源。 -当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `Phase` -将变为 `Failed`。 -如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 -Kubernetes 来调度。 - -## {{% heading "whatsnext" %}} - - -- 阅读[配置资源不足的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)， - 进一步了解驱逐信号和阈值。 - diff --git a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md index 65306db584..c950fb1e20 100644 --- a/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -95,7 +95,7 @@ the API server about this decision in a process called _binding_. kube-apiserver，这个过程叫做 _绑定_。 -如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间亲和性， +如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间{{< glossary_tooltip text="亲和性" term_id="affinity" >}}， 则在没有这些较低优先级 Pod 的情况下，无法满足 Pod 间亲和性规则。 在这种情况下，调度程序不会抢占节点上的任何 Pod。 相反，它寻找另一个节点。调度程序可能会找到合适的节点， @@ -620,7 +620,7 @@ Pod 优先级和 {{}} 或者最低优先级的 Pod 受 PodDisruptionBudget 保护时，才会考虑优先级较高的 Pod。 kubelet 使用优先级来确定 -[资源不足时驱逐](/zh/docs/tasks/administer-cluster/out-of-resource/) Pod 的顺序。 +[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) Pod 的顺序。 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名： 1. 对紧俏资源的使用是否超过请求值 1. Pod 优先级 1. 相对于请求的资源使用量 -有关更多详细信息，请参阅[驱逐最终用户的 Pod](/zh/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)。 +有关更多详细信息，请参阅 +[kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 -当某 Pod 的资源用量未超过其请求时，kubelet 资源不足驱逐不会驱逐该 Pod。 +当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。 如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。 另一个优先级高于其请求的 Pod 可能会被驱逐。 diff --git a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md index b8c097e5df..08eb73003a 100644 --- a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -32,60 +32,70 @@ The kube-scheduler can be configured to enable bin packing of resources along wi ## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 -在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存） -的请求数量和可用容量 之比率对节点评分。 -Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重， +Kubernetes 允许用户指定资源以及每类资源的权重， 以便根据请求数量与可用容量之比率为节点评分。 这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。 `RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 -`requestedToCapacityRatioArguments` 的配置选项进行控制。 +`RequestedToCapacityRatioArgs` 的配置选项进行控制。 该标志由两个参数 `shape` 和 `resources` 组成。 -`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求 -（least requested）或 -最多请求（most requested）计算。 +`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为 +最少请求（least requested）或最多请求（most requested）计算。 `resources` 包含由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源， `weight` 指定每种资源的权重。 以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源 `intel.com/foo` 和 `intel.com/bar` 的装箱行为 -```json -{ - "kind": "Policy", - "apiVersion": "v1", - ... - "priorities": [ - ... - { - "name": "RequestedToCapacityRatioPriority", - "weight": 2, - "argument": { - "requestedToCapacityRatioArguments": { - "shape": [ - {"utilization": 0, "score": 0}, - {"utilization": 100, "score": 10} - ], - "resources": [ - {"name": "intel.com/foo", "weight": 3}, - {"name": "intel.com/bar", "weight": 5} - ] - } - } - } - ], -} +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: +# ... + pluginConfig: + - name: RequestedToCapacityRatio + args: + shape: + - utilization: 0 + score: 10 + - utilization: 100 + score: 0 + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 5 ``` + +使用 kube-scheduler 标志 `--config=/path/to/config/file` +引用 `KubeSchedulerConfiguration` 文件将配置传递给调度器。 + diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 8a43385d13..398a06f18d 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -81,11 +81,11 @@ kube-scheduler 的表现等价于设置值为 100。 -要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) +要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) 然后重启调度器。 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。 @@ -298,6 +298,6 @@ After going over all the Nodes, it goes back to Node 1. ## {{% heading "whatsnext" %}} - + -* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 1107c19565..303b707a2f 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -16,7 +16,7 @@ weight: 90 -{{< feature-state for_k8s_version="1.15" state="alpha" >}} +{{< feature-state for_k8s_version="1.19" state="stable" >}} + +控制平面使用节点{{}}自动创建 +与[节点状况](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。 + +调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。 +例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面 +添加 `node.kubernetes.io/disk-pressure` 污点并且不会调度新的 pod +到受影响的节点。如果 `MemoryPressure` 节点状况处于活跃状态，则 +控制平面添加 `node.kubernetes.io/memory-pressure` 污点。 + + + +对于新创建的 Pod，可以通过添加相应的 Pod 容忍度来忽略节点状况。 +控制平面还在具有除 `BestEffort` 之外的 {{}}的 pod 上 +添加 `node.kubernetes.io/memory-pressure` 容忍度。 +这是因为 Kubernetes 将 `Guaranteed` 或 `Burstable` QoS 类中的 Pod（甚至没有设置内存请求的 Pod） +视为能够应对内存压力，而新创建的 `BestEffort` Pod 不会被调度到受影响的节点上。 + + -Node 生命周期控制器会自动创建与 Node 条件相对应的带有 `NoSchedule` 效应的污点。 -同样，调度器不检查节点条件，而是检查节点污点。这确保了节点条件不会影响调度到节点上的内容。 -用户可以通过添加适当的 Pod 容忍度来选择忽略某些 Node 的问题(表示为 Node 的调度条件)。 DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍度以防 DaemonSet 崩溃： @@ -512,8 +542,8 @@ arbitrary tolerations to DaemonSets. ## {{% heading "whatsnext" %}} -* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为 -* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/) +* 阅读[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)，以及如何配置其行为 +* 阅读 [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index 50a6c47d86..7864aad7d8 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -92,10 +92,10 @@ options ndots:5 概括起来，名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者 -`data.prod.cluster.local`。 +`data.prod.svc.cluster.local`。 ### Pod 的 setHostnameAsFQDN 字段 {#pod-sethostnameasfqdn-field} -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} ### Pod 的 DNS 配置 {#pod-dns-config} +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。 `dnsConfig` 字段是可选的，它可以与任何 `dnsPolicy` 设置一起使用。 @@ -541,6 +545,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom options ndots:5 ``` + +#### 扩展 DNS 配置 {#expanded-dns-configuration} + +{{< feature-state for_k8s_version="1.22" state="alpha" >}} + +对于 Pod DNS 配置，Kubernetes 默认允许最多 6 个 搜索域（ Search Domain） +以及一个最多 256 个字符的搜索域列表。 + +如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个 +搜索域以及一个最多 2048 个字符的搜索域列表。 + -* 了解[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices) * 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index 2364096a53..c1ee7b6078 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -421,7 +421,7 @@ IngressClass 资源包含一个可选的 `parameters` 字段，可用于为该 --> #### 名字空间域的参数 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} `parameters` 字段有一个 `scope` 和 `namespace` 字段，可用来引用特定 于名字空间的资源，对 Ingress 类进行配置。 @@ -436,6 +441,9 @@ will reference a parameters resource in a specific namespace: 将 `scope` 设置为 `Namespace` 并设置 `namespace` 字段就可以引用某特定 名字空间中的参数资源。 +有了名字空间域的参数，就不再需要为一个参数资源配置集群范围的 CustomResourceDefinition。 +除此之外，之前对访问集群范围的资源进行授权，需要用到 RBAC 相关的资源，现在也不再需要了。 + {{< codenew file="service/networking/namespaced-params.yaml" >}} ## SCTP 支持 -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -作为一个 Beta 特性，SCTP 支持默认是被启用的。 +作为一个稳定特性，SCTP 支持默认是被启用的。 要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定 `--feature-gates=SCTPSupport=false,...` 来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 @@ -439,7 +440,7 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha --> ## 针对某个端口范围 {#targeting-a-range-of-ports} -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} 上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议 与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。 使用此字段时存在以下限制： -* 作为一种 Alpha 阶段的特性，端口范围设定默认是被禁用的。要在整个集群 - 范围内允许使用 `endPort` 字段，你（或者你的集群管理员）需要为 API - 服务器设置 `-feature-gates=NetworkPolicyEndPort=true,...` 以启用 +* 作为一种 Beta 阶段的特性，端口范围设定默认是被启用的。要在整个集群 + 范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API + 服务器设置 `-feature-gates=NetworkPolicyEndPort=false,...` 以禁用 `NetworkPolicyEndPort` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 * `endPort` 字段必须等于或者大于 `port` 字段的值。 @@ -499,9 +502,15 @@ The following restrictions apply when using this field: 你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件 必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。 +如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy， +策略只对单个 `port` 字段生效。 {{< /note >}} ### 超出容量的 Endpoints {#over-capacity-endpoints} -如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.21 版本 +如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.22 版本 （及更新版本）的集群会将为该 Endpoints 添加注解 -`endpoints.kubernetes.io/over-capacity: warning`。 -这一注解表明所影响到的 Endpoints 对象已经超出容量。 +`endpoints.kubernetes.io/over-capacity: truncated`。 +这一注解表明所影响到的 Endpoints 对象已经超出容量，此外 Endpoints 控制器还会将 Endpoints 对象数量截断到 1000。 +## 流量策略 {#traffic-policies} + + +### 外部流量策略 {#external-traffic-policy} + + + +你可以通过设置 `spec.externalTrafficPolicy` 字段来控制来自于外部的流量是如何路由的。 +可选值有 `Cluster` 和 `Local`。字段设为 `Cluster` 会将外部流量路由到所有就绪的端点， +设为 `Local` 会只路由到当前节点上就绪的端点。 +如果流量策略设置为 `Local`，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。 + +{{< note >}} +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + + + +如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 + + + +如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 `Local` 的外部流量策略。 +在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的 +状态健康的端点，如同外部流量策略设为 `Cluster`。 + + +针对处于正被终止状态的端点这一转发行为使得外部负载均衡器可以优雅地排出由 +`NodePort` 服务支持的连接，就算是健康检查节点端口开始失败也是如此。 +否则，当节点还在负载均衡器的节点池内，在 Pod 终止过程中的流量会被丢掉，这些流量可能会丢失。 + +{{< /note >}} + + +### 内部流量策略 {#internal-traffic-policy} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + + +你可以设置 `spec.internalTrafficPolicy` 字段来控制内部来源的流量是如何转发的。可设置的值有 `Cluster` 和 `Local`。 +将字段设置为 `Cluster` 会将内部流量路由到所有就绪端点，设置为 `Local` 只会路由到当前节点上就绪的端点。 +如果流量策略是 `Local`，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。 + #### 设置负载均衡器实现的类别 {#load-balancer-class} -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} -从 v1.21 开始，你可以有选择地为 `LoadBalancer` 类型的服务设置字段 -`.spec.loadBalancerClass`，以指定其负载均衡器实现的类别。 -默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，`LoadBalancer` 类型 -服务会使用云提供商的默认负载均衡器实现。 +`spec.loadBalancerClass` 允许你不使用云提供商的默认负载均衡器实现，转而使用指定的负载均衡器实现。 +这个特性从 v1.21 版本开始可以使用，你在 v1.21 版本中使用这个字段必须启用 `ServiceLoadBalancerClass` +特性门控，这个特性门控从 v1.22 版本及以后默认打开。 +默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，如果集群使用 `--cloud-provider` 配置了云提供商， +`LoadBalancer` 类型服务会使用云提供商的默认负载均衡器实现。 如果设置了 `.spec.loadBalancerClass`，则假定存在某个与所指定的类相匹配的 负载均衡器实现在监视服务变化。 所有默认的负载均衡器实现（例如，由云提供商所提供的）都会忽略设置了此字段 @@ -1152,12 +1230,10 @@ Once set, it cannot be changed. The value of `spec.loadBalancerClass` must be a label-style identifier, with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". Unprefixed names are reserved for end-users. -You must enable the `ServiceLoadBalancerClass` feature gate to use this field. --> `.spec.loadBalancerClass` 的值必须是一个标签风格的标识符， 可以有选择地带有类似 "`internal-vip`" 或 "`example.com/internal-vip`" 这类 前缀。没有前缀的名字是保留给最终用户的。 -你必须启用 `ServiceLoadBalancerClass` 特性门控才能使用此字段。 - - - - -在阅读这篇文档之前，强烈建议你先熟悉一下 [Kubernetes 日志概况](/zh/docs/concepts/cluster-administration/logging) - - - -{{< note >}} -默认情况下，Stackdriver 日志机制仅收集容器的标准输出和标准错误流。 -如果要收集你的应用程序写入一个文件（例如）的任何日志，请参见 Kubernetes 日志概述中的 [sidecar 方式](/zh/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent) -{{< /note >}} - - - - - -## 部署 {#deploying} - - -为了接收日志，你必须将 Stackdriver 日志代理部署到集群中的每个节点。 -此代理是一个已配置的 `fluentd`，其配置存在一个 `ConfigMap` 中，且实例使用 Kubernetes 的 `DaemonSet` 进行管理。 -`ConfigMap` 和 `DaemonSet` 的实际部署，取决你的集群设置。 - - - -### 部署到一个新的集群 - -#### Google Kubernetes Engine - - -对于部署在 Google Kubernetes Engine 上的集群，Stackdriver 是默认的日志解决方案。 -Stackdriver 日志机制会默认部署到你的新集群上，除非你明确地不选择。 - - - -#### 其他平台 - - -为了将 Stackdriver 日志机制部署到你正在使用 `kube-up.sh` 创建的*新*集群上，执行如下操作： - - -1. 设置环境变量 `KUBE_LOGGING_DESTINATION` 为 `gcp`。 -1. **如果不是跑在 GCE 上**，在 `KUBE_NODE_LABELS` 变量中包含 `beta.kubernetes.io/fluentd-ds-ready=true`。 - - - -集群启动后，每个节点都应该运行 Stackdriver 日志代理。 -`DaemonSet` 和 `ConfigMap` 作为附加组件进行配置。 -如果你不是使用 `kube-up.sh`，可以考虑不使用预先配置的日志方案启动集群，然后部署 Stackdriver 日志代理到正在运行的集群。 - - - -{{< warning >}} -除了 Google Kubernetes Engine，Stackdriver 日志守护进程在其他的平台有已知的问题。 -请自行承担风险。 -{{< /warning >}} - - -### 部署到一个已知集群 - - -1. 在每个节点上打标签（如果尚未存在） - - - Stackdriver 日志代理部署使用节点标签来确定应该将其分配到给哪些节点。 - 引入这些标签是为了区分 Kubernetes 1.6 或更高版本的节点。 - 如果集群是在配置了 Stackdriver 日志机制的情况下创建的，并且节点的版本为 1.5.X 或更低版本，则它将使用 fluentd 用作静态容器。 - 节点最多只能有一个 fluentd 实例，因此只能将标签打在未分配过 fluentd pod 的节点上。 - 你可以通过运行 `kubectl describe` 来确保你的节点被正确标记，如下所示： - - ``` - kubectl describe node $NODE_NAME - ``` - - 输出应类似于如下内容： - - ``` - Name: NODE_NAME - Role: - Labels: beta.kubernetes.io/fluentd-ds-ready=true - ... - ``` - - 确保输出内容包含 `beta.kubernetes.io/fluentd-ds-ready=true` 标签。 - 如果不存在，则可以使用 `kubectl label` 命令添加，如下所示： - - ``` - kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true - ``` - - - {{< note >}} - 如果节点发生故障并且必须重新创建，则必须将标签重新打在重新创建了的节点。 - 为了让此操作更便捷，你可以在节点启动脚本中使用 Kubelet 的命令行参数给节点添加标签。 - {{< /note >}} - - -2. 通过运行以下命令，部署一个带有日志代理配置的 `ConfigMap`： - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml - ``` - - 该命令在 `default` 命名空间中创建 `ConfigMap`。你可以在创建 `ConfigMap` 对象之前手动下载文件并进行更改。 - - -3. 通过运行以下命令，部署日志代理的 `DaemonSet`： - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml - ``` - - 你也可以在使用前下载和编辑此文件。 - - -## 验证日志代理部署 - - -部署 Stackdriver `DaemonSet` 之后，你可以通过运行以下命令来查看日志代理的部署状态： - -```shell -kubectl get ds --all-namespaces -``` - - -如果你的集群中有 3 个节点，则输出应类似于如下： - -``` -NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE -... -default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m -... -``` - - -要了解使用 Stackdriver 进行日志记录的工作方式，请考虑以下具有日志生成的 pod 定义 [counter-pod.yaml](/examples/debug/counter-pod.yaml)： - -{{< codenew file="debug/counter-pod.yaml" >}} - - -这个 pod 定义里有一个容器，该容器运行一个 bash 脚本，脚本每秒写一次计数器的值和日期时间，并无限期地运行。 -让我们在默认命名空间中创建此 pod。 - -```shell -kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml -``` - - -你可以观察到正在运行的 pod： - -```shell -kubectl get pods -``` -``` -NAME READY STATUS RESTARTS AGE -counter 1/1 Running 0 5m -``` - - -在短时间内，你可以观察到 "pending" 的 pod 的状态，因为 kubelet 必须先下载容器镜像。 -当 pod 状态变为 `Running` 时，你可以使用 `kubectl logs` 命令查看此 counter pod 的输出。 - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... -``` - - -正如日志概览所述，此命令从容器日志文件中获取日志项。 -如果该容器被 Kubernetes 杀死然后重新启动，你仍然可以访问前一个容器的日志。 -但是，如果将 Pod 从节点中驱逐，则日志文件会丢失。让我们通过删除当前运行的 counter 容器来演示这一点： - -```shell -kubectl delete pod counter -``` -``` -pod "counter" deleted -``` - - -然后重建它： - -```shell -kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml -``` -``` -pod/counter created -``` - - -一段时间后，你可以再次从 counter pod 访问日志： - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:01:00 UTC 2001 -1: Mon Jan 1 00:01:01 UTC 2001 -2: Mon Jan 1 00:01:02 UTC 2001 -... -``` - - -如预期的那样，日志中仅出现最近的日志记录。 -但是，对于实际应用程序，你可能希望能够访问所有容器的日志，特别是出于调试的目的。 -这就是先前启用的 Stackdriver 日志机制可以提供帮助的地方。 - - -## 查看日志 - - -Stackdriver 日志代理为每个日志项关联元数据，供你在后续的查询中只选择感兴趣的消息： -例如，来自某个特定 Pod 的消息。 - - -元数据最重要的部分是资源类型和日志名称。 -容器日志的资源类型为 `container`，在用户界面中名为 `GKE Containers`（即使 Kubernetes 集群不在 Google Kubernetes Engine 上）。 -日志名称是容器的名称，因此，如果你有一个包含两个容器的 pod，在 spec 中名称定义为 `container_1` 和 `container_2`，则它们的日志的名称分别为 `container_1` 和 `container_2`。 - - -系统组件的资源类型为 `compute`，在接口中名为 `GCE VM Instance`。 -系统组件的日志名称是固定的。 -对于 Google Kubernetes Engine 节点，系统组件中的每个日志项都具有以下日志名称之一： - -* docker -* kubelet -* kube-proxy - - -你可以在[Stackdriver 专用页面](https://cloud.google.com/logging/docs/view/overview) -上了解有关查看日志的更多信息。 - - -查看日志的一种可能方法是使用 [Google Cloud SDK](https://cloud.google.com/sdk/) -中的 [`gcloud logging`](https://cloud.google.com/logging/docs/reference/tools/gcloud-logging) -命令行接口。 -它使用 Stackdriver 日志机制的 -[过滤语法](https://cloud.google.com/logging/docs/view/advanced_filters)查询特定日志。 -例如，你可以运行以下命令： - -```none -gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload' -``` -``` -... -"2: Mon Jan 1 00:01:02 UTC 2001\n" -"1: Mon Jan 1 00:01:01 UTC 2001\n" -"0: Mon Jan 1 00:01:00 UTC 2001\n" -... -"2: Mon Jan 1 00:00:02 UTC 2001\n" -"1: Mon Jan 1 00:00:01 UTC 2001\n" -"0: Mon Jan 1 00:00:00 UTC 2001\n" -``` - - -如你所见，尽管 kubelet 已经删除了第一个容器的日志，日志中仍会包含 counter -容器第一次和第二次运行时输出的消息。 - - -### 导出日志 - - -你可以将日志导出到 [Google Cloud Storage](https://cloud.google.com/storage/) 或 -[BigQuery](https://cloud.google.com/bigquery/) 进行进一步的分析。 -Stackdriver 日志机制提供了接收器（Sink）的概念，你可以在其中指定日志项的存放地。 -可在 Stackdriver [导出日志页面](https://cloud.google.com/logging/docs/export/configure_export_v2) -上获得更多信息。 - - -## 配置 Stackdriver 日志代理 - - -有时默认的 Stackdriver 日志机制安装可能无法满足你的需求，例如： - - -* 你可能需要添加更多资源，因为默认的行为表现无法满足你的需求。 -* 你可能需要引入额外的解析机制以便从日志消息中提取更多元数据，例如严重性或源代码引用。 -* 你可能想要将日志不仅仅发送到 Stackdriver 或仅将部分日志发送到 Stackdriver。 - - -在这种情况下，你需要更改 `DaemonSet` 和 `ConfigMap` 的参数。 - - -### 先决条件 - - -如果使用的是 GKE，并且集群中启用了 Stackdriver 日志机制，则无法更改其配置， -因为它是由 GKE 管理和支持的。 -但是，你可以禁用默认集成的日志机制并部署自己的。 - - -{{< note >}} -你将需要自己支持和维护新部署的配置了：更新映像和配置、调整资源等等。 -{{< /note >}} - - -若要禁用默认的日志记录集成，请使用以下命令： - -``` -gcloud beta container clusters update --logging-service=none CLUSTER -``` - - -你可以在[部署部分](#deploying)中找到有关如何将 Stackdriver 日志代理安装到 -正在运行的集群中的说明。 - - -### 更改 `DaemonSet` 参数 {#changing-daemonset-parameters} - - -当集群中有 Stackdriver 日志机制的 `DaemonSet` 时，你只需修改其 spec 中的 -`template` 字段，DaemonSet 控制器将为你管理 Pod。 -例如，假设你按照上面的描述已经安装了 Stackdriver 日志机制。 -现在，你想更改内存限制，来给 fluentd 提供的更多内存，从而安全地处理更多日志。 - - -获取集群中运行的 `DaemonSet` 的 spec： - -```shell -kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml -``` - - -然后在 spec 文件中编辑资源需求，并使用以下命令更新 apiserver 中的 `DaemonSet` 对象： - -```shell -kubectl replace -f fluentd-gcp-ds.yaml -``` - - -一段时间后，Stackdriver 日志代理的 pod 将使用新配置重新启动。 - - -### 更改 fluentd 参数 - - -Fluentd 的配置存在 `ConfigMap` 对象中。 -它实际上是一组合并在一起的配置文件。 -你可以在[官方网站](https://docs.fluentd.org)上了解 fluentd 的配置。 - - -假设你要向配置添加新的解析逻辑，以便 fluentd 可以理解默认的 Python 日志记录格式。 -一个合适的 fluentd 过滤器类似如下： - -``` - - type parser - format /^(?\w):(?\w):(?.*)/ - reserve_data true - suppress_parse_error_log true - key_name log - -``` - - -现在，你需要将其放入配置中，并使 Stackdriver 日志代理感知它。 -通过运行以下命令，获取集群中当前版本的 Stackdriver 日志机制的 `ConfigMap`： - -```shell -kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml -``` - - -然后在 `containers.input.conf` 键的值中，在 `source` 部分之后插入一个新的过滤器。 - - - -{{< note >}} -顺序很重要。 -{{< /note >}} - - -在 apiserver 中更新 `ConfigMap` 比更新 `DaemonSet` 更复杂。 -最好考虑 `ConfigMap` 是不可变的。 -如果是这样，要更新配置，你应该使用新名称创建 `ConfigMap`，然后使用 -[上面的指南](#changing-daemonset-parameters)将 `DaemonSet` 更改为指向它。 - - -### 添加 fluentd 插件 - - -Fluentd 用 Ruby 编写，并允许使用 [plugins](https://www.fluentd.org/plugins) 扩展其功能。 -如果要使用默认的 Stackdriver 日志机制容器镜像中未包含的插件，则必须构建自定义镜像。 -假设你要为来自特定容器添加 Kafka 信息接收器，以进行其他处理。 -你可以复用默认的[容器镜像源](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)，并仅添加少量更改： - - -* 将 Makefile 更改为指向你的容器仓库，例如 `PREFIX=gcr.io/`。 -* 将你的依赖项添加到 Gemfile 中，例如 `gem 'fluent-plugin-kafka'`。 - - -然后在该目录运行 `make build push`。 -在更新 `DaemonSet` 以使用新镜像后，你就可以使用在 fluentd 配置中安装的插件了。 - diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index a575bc57cf..603274f5c2 100644 --- a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -139,7 +139,7 @@ Removing an old version: If this occurs, switch back to using `served:true` on the old version, migrate the remaining clients to the new version and repeat this step. 1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed. - 1. Verify that the `stored` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. + 1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. 1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`. 1. Remove the old version from the CustomResourceDefinition `spec.versions` list. 1. Drop conversion support for the old version in conversion webhooks. @@ -156,7 +156,7 @@ Removing an old version: 1. 确保已完成[将现有对象升级到新存储版本](#upgrade-existing-objects-to-a-new-stored-version) 的步骤。 1. 在 CustomResourceDefinition 的 `spec.versions` 列表中，确认新版本的 - `stored` 已被设置为 `true`。 + `storage` 已被设置为 `true`。 2. 确认旧版本不在 CustomResourceDefinition `status.storedVersions` 中。 1. 从 CustomResourceDefinition `spec.versions` 列表中删除旧版本。 1. 在转换 Webhooks 中放弃对旧版本的转换支持。 @@ -302,7 +302,7 @@ spec: plural: crontabs # 名称的单数形式，用于在命令行接口和显示时作为其别名 singular: crontab - # kind 通常是驼峰编码（CamelCased）的单数形式，用于资源清单中 + # kind 通常是大驼峰编码（PascalCased）的单数形式，用于资源清单中 kind: CronTab # shortNames 允许你在命令行接口中使用更短的字符串来匹配你的资源 shortNames: @@ -1244,8 +1244,8 @@ If conversion fails, a webhook should return a `response` stanza containing the --> 如果转换失败，则 Webhook 应该返回包含以下字段的 `response` 节： -*`uid`，从发送到 Webhook 的 `request.uid` 复制而来 -*`result`，设置为 `{"status": "Failed"}` +* `uid`，从发送到 Webhook 的 `request.uid` 复制而来 +* `result`，设置为 `{"status": "Failed"}` {{< warning >}} ## 集群 -* [AppArmor](/zh/docs/tutorials/clusters/apparmor/) +* [seccomp](/zh/docs/tutorials/clusters/seccomp/) ### 使用 PodSecurityPolicy 限制配置文件 +{{< note >}} + +PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版本移除。 +查看 [PodSecurityPolicy 文档](/zh/docs/concepts/policy/pod-security-policy/)获取更多信息。 +{{< /note >}} + 如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。要启用 PodSecurityPolicy，必须在“apiserver”上设置以下标志： diff --git a/content/zh/docs/tutorials/clusters/seccomp.md b/content/zh/docs/tutorials/clusters/seccomp.md index 9f8d7dc2f3..d724d605b6 100644 --- a/content/zh/docs/tutorials/clusters/seccomp.md +++ b/content/zh/docs/tutorials/clusters/seccomp.md @@ -2,6 +2,7 @@ title: 使用 Seccomp 限制容器的系统调用 content_type: tutorial weight: 20 +min-kubernetes-server-version: v1.22 --- @@ -10,7 +11,7 @@ weight: 20 为了完成本教程中的所有步骤，你必须安装 [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) -和 [kubectl](/zh/docs/tasks/tools/)。本教程将显示同时具有 alpha（v1.19 之前的版本） -和通常可用的 seccomp 功能的示例，因此请确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。 +和 [kubectl](/zh/docs/tasks/tools/)。本教程将显示同时具有 alpha（v1.22 新版本） +和通常可用的 seccomp 功能的示例。 +你应该确保为所使用的版本[正确配置](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)了集群。 + + +## 启用 `RuntimeDefault` 作为所有工作负载的默认 seccomp 配置文件 + +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} + +`SeccompDefault` 是一个可选的 kubelet +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)， +相应地，`--seccomp-default` 是此特性门控的 +[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)。 +必须同时启用两者才能使用该功能。 + + +如果启用，kubelet 将默认使用 `RuntimeDefault` seccomp 配置， +而不是使用 `Unconfined`（禁用 seccomp）模式，该配置由容器运行时定义。 +默认配置旨在提供一组强大的安全默认值设置，同时避免影响工作负载的功能。 +不同的容器运行时之间及其不同的发布版本之间的默认配置可能不同， +例如在比较 CRI-O 和 containerd 的配置文件时（就会发现这点）。 + + +某些工作负载可能相比其他工作负载需要更少的系统调用限制。 +这意味着即使使用 `RuntimeDefault` 配置文件，它们也可能在运行时失败。 +要处理此类失效，你可以： + +- 将工作负载显式运行为 `Unconfined`。 +- 禁用节点的 `SeccompDefault` 功能。 + 还要确保工作负载被安排在禁用该功能的节点上。 +- 为工作负载创建自定义 seccomp 配置文件。 + + +如果你将此功能引入到类似生产的集群中， +Kubernetes 项目建议你在节点的子集上启用此特性门控， +然后在集群范围内推出更改之前测试工作负载的执行情况。 + +有关可能的升级和降级策略的更多详细信息， +请参见[相关 Kubernetes 增强提案 (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy)。 + + +由于该功能处于 alpha 状态，因此默认情况下是被禁用的。要启用它， +请将标志 `--feature-gates=SeccompDefault=true --seccomp-default` +传递给 `kubelet` CLI 或通过 +[kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)启用它。 +要在 [kind](https://kind.sigs.k8s.io) 中启用特性门控， +请确保 `kind` 提供所需的最低 Kubernetes 版本并 +[在 kind 配置中](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster) +启用 `SeccompDefault` 功能： + +```yaml +kind: Cluster +apiVersion: kind.x-k8s.io/v1alpha4 +featureGates: + SeccompDefault: true +``` + -## 使用 Seccomp 配置文件创建 Pod 以进行系统调用审核 +## 使用 seccomp 配置文件创建 Pod 以进行系统调用审核 首先，将 `audit.json` 配置文件应用到新的 Pod 中，该配置文件将记录该进程的所有系统调用。 @@ -297,14 +396,14 @@ kubectl delete svc/audit-pod ``` -## 使用导致违规的 Seccomp 配置文件创建 Pod +## 使用导致违规的 seccomp 配置文件创建 Pod 为了进行演示，请将不允许任何系统调用的配置文件应用于 Pod。 @@ -364,7 +463,7 @@ kubectl delete svc/violation-pod ``` -## 使用设置仅允许需要的系统调用的配置文件来创建 Pod +## 使用设置仅允许需要的系统调用的 seccomp 配置文件来创建 Pod 如果你看一下 `fine-pod.json` 文件，你会注意到在第一个示例中配置文件设置为 `"defaultAction": "SCMP_ACT_LOG"` 的一些系统调用。 现在，配置文件设置为 `"defaultAction": "SCMP_ACT_ERRNO"`，但是在 `"action": "SCMP_ACT_ALLOW"` 块中明确允许一组系统调用。 @@ -482,7 +581,7 @@ kubectl delete svc/fine-pod ``` -## 使用容器运行时默认的 Seccomp 配置文件创建 Pod +## 使用容器运行时默认的 seccomp 配置文件创建 Pod 大多数容器运行时都提供一组允许或不允许的默认系统调用。通过使用 `runtime/default` 注释 或将 Pod 或容器的安全上下文中的 seccomp 类型设置为 `RuntimeDefault`，可以轻松地在 Kubernetes 中应用默认值。 @@ -518,10 +617,10 @@ The default seccomp profile should provide adequate access for most workloads. 额外的资源： -* [Seccomp 概要](https://lwn.net/Articles/656307/) +* [seccomp 概要](https://lwn.net/Articles/656307/) * [Seccomp 在 Docker 中的安全配置](https://docs.docker.com/engine/security/seccomp/) \ No newline at end of file diff --git a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md index 027771a28c..fc6f0fa2f1 100644 --- a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -79,7 +79,7 @@ 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 +kubectl apply -f https://k8s.io/examples/pods/config/redis-pod.yaml ``` {{< note >}} -`dashboard` 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。 +`dashboard` 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。 +你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。 如果你以 root 用户身份在环境中运行， 请参见[使用 URL 打开仪表板](#open-dashboard-with-url)。 +默认情况下，仪表板只能从内部 Kubernetes 虚拟网络中访问。 +`dashboard` 命令创建一个临时代理，使仪表板可以从 Kubernetes 虚拟网络外部访问。 + 要停止代理，请运行 `Ctrl+C` 退出该进程。仪表板仍在运行中。 +命令退出后，仪表板仍然在 Kubernetes 集群中运行。 +你可以再次运行 `dashboard` 命令创建另一个代理来访问仪表板。 + {{< /note >}} 使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet。 -请确保提供了 `--cascade=false` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 +请确保提供了 `--cascade=orphan` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 ```shell -kubectl delete statefulset web --cascade=false +kubectl delete statefulset web --cascade=orphan ``` ``` statefulset.apps "web" deleted @@ -1416,9 +1416,10 @@ kubectl get pods -w -l app=nginx -在另一个窗口中再次删除这个 StatefulSet。这次省略 `--cascade=false` 参数。 +在另一个窗口中再次删除这个 StatefulSet。这次省略 `--cascade=orphan` 参数。 ```shell kubectl delete statefulset web diff --git a/content/zh/docs/tutorials/stateful-application/cassandra.md b/content/zh/docs/tutorials/stateful-application/cassandra.md index d3a4d7e118..461b050938 100644 --- a/content/zh/docs/tutorials/stateful-application/cassandra.md +++ b/content/zh/docs/tutorials/stateful-application/cassandra.md @@ -87,14 +87,14 @@ To complete this tutorial, you should already have a basic familiarity with ### Additional Minikube setup instructions {{< caution >}} -[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU. +[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 2048MB of memory and 2 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings: --> ### 额外的 Minikube 设置说明 {{< caution >}} -[Minikube](https://minikube.sigs.k8s.io/docs/)默认为 1024MiB 内存和 1 个 CPU。 +[Minikube](https://minikube.sigs.k8s.io/docs/)默认为 2048MB 内存和 2 个 CPU。 在本教程中，使用默认资源配置运行 Minikube 会导致资源不足的错误。为避免这些错误，请使用以下设置启动 Minikube： ```shell diff --git a/content/zh/docs/tutorials/stateful-application/zookeeper.md b/content/zh/docs/tutorials/stateful-application/zookeeper.md index 3f5baf3c27..7f3a0e9548 100644 --- a/content/zh/docs/tutorials/stateful-application/zookeeper.md +++ b/content/zh/docs/tutorials/stateful-application/zookeeper.md @@ -1412,7 +1412,7 @@ drain the node on which the `zk-0` Pod is scheduled. 来隔离和腾空 `zk-0` Pod 调度所在的节点。 ```shell -kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` @@ -1453,7 +1453,7 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node 在第一个终端中持续观察 StatefulSet 的 Pods 并腾空 `zk-1` 调度所在的节点。 ```shell -kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned +kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force -delete-emptydir-data "kubernetes-node-ixsl" cordoned ``` ``` @@ -1504,7 +1504,7 @@ Continue to watch the Pods of the stateful set, and drain the node on which 继续观察 StatefulSet 中的 Pods 并腾空 `zk-2` 调度所在的节点。 ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` node "kubernetes-node-i4c4" cordoned @@ -1610,7 +1610,7 @@ Attempt to drain the node on which `zk-2` is scheduled. 尝试腾空 `zk-2` 调度所在的节点。 ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` -* 单实例 [Redis](https://www.redis.com/) 以保存留言板条目 +* 单实例 [Redis](https://www.redis.io/) 以保存留言板条目 * 多个 web 前端实例 ## {{% heading "objectives" %}} diff --git a/static/_redirects b/static/_redirects index a46cc64c38..3274c895a7 100644 --- a/static/_redirects +++ b/static/_redirects @@ -209,12 +209,12 @@ /docs/reference/generated/kube-scheduler/ /docs/reference/command-line-tools-reference/kube-scheduler/ 301 /docs/reference/generated/kubectl/kubectl-options/ /docs/reference/kubectl/kubectl/ 301 /docs/reference/generated/kubectl/kubectl/ /docs/reference/generated/kubectl/kubectl-commands/ 301 -/docs/reference/generated/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 +/docs/reference/generated/kubectl/kubectl/kubectl_* /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301 /docs/reference/kubectl/kubectl-cmds/ /docs/reference/generated/kubectl/kubectl-commands/ 301! -/docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 +/docs/reference/kubectl/kubectl/kubectl_* /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/ /docs/reference/scheduling/config/#profiles 301 /docs/reference/generated/kubernetes-api/v1.15/ https://v1-15.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/ 301 @@ -400,7 +400,7 @@ /docs/user-guide/kubectl-conventions/ /docs/reference/kubectl/conventions/ /docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/ /cheatsheet /docs/reference/kubectl/cheatsheet/ 302 -/docs/user-guide/kubectl/kubectl_*/ /docs/reference/generated/kubectl/kubectl-commands#:splat 301 +/docs/user-guide/kubectl/kubectl_* /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/user-guide/labels/ /docs/concepts/overview/working-with-objects/labels/ 301 /docs/user-guide/liveness/ /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 301 /docs/user-guide/load-balancer/ /docs/tasks/access-application-cluster/create-external-load-balancer/ 301