diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss index 20025064d2..958b738907 100644 --- a/assets/scss/_base.scss +++ b/assets/scss/_base.scss @@ -673,18 +673,19 @@ section#cncf { width: 100%; overflow: hidden; clear: both; + display: flex; + justify-content: space-evenly; + flex-wrap: wrap; h4 { line-height: normal; margin-bottom: 15px; } - & > div:first-child { - float: left; - } - - & > div:last-child { - float: right; + & > div { + background-color: #daeaf9; + border-radius: 20px; + padding: 25px; } } diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 1660b74c31..6f5a4c1f6d 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -354,12 +354,48 @@ main { word-break: break-word; } +/* SCSS Related to the Metrics Table */ + + @media (max-width: 767px) { // for mobile devices, Display the names, Stability levels & types + + table.metrics { + th:nth-child(n + 4), + td:nth-child(n + 4) { + display: none; + } + + td.metric_type{ + min-width: 7em; + } + td.metric_stability_level{ + min-width: 6em; + } + } + } + + table.metrics tbody{ // Tested dimensions to improve overall aesthetic of the table + tr { + td { + font-size: smaller; + } + td.metric_labels_varying{ + min-width: 9em; + } + td.metric_type{ + min-width: 9em; + } + td.metric_description{ + min-width: 10em; + } + + } + } + table.no-word-break td, table.no-word-break code { word-break: normal; - } } - +} // blockquotes and callouts diff --git a/content/en/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md b/content/en/blog/_posts/2023-08-16-non-graceful-node-shutdown-to-ga.md similarity index 99% rename from content/en/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md rename to content/en/blog/_posts/2023-08-16-non-graceful-node-shutdown-to-ga.md index 6e5e12ec46..16c2c0550d 100644 --- a/content/en/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md +++ b/content/en/blog/_posts/2023-08-16-non-graceful-node-shutdown-to-ga.md @@ -1,7 +1,7 @@ --- layout: blog title: "Kubernetes 1.28: Non-Graceful Node Shutdown Moves to GA" -date: 2023-08-15T10:00:00-08:00 +date: 2023-08-16T10:00:00-08:00 slug: kubernetes-1-28-non-graceful-node-shutdown-GA --- diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 4e5c6f460b..a1763b9459 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -216,8 +216,6 @@ data has the following advantages: - improves performance of your cluster by significantly reducing load on kube-apiserver, by closing watches for ConfigMaps marked as immutable. -This feature is controlled by the `ImmutableEphemeralVolumes` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/). You can create an immutable ConfigMap by setting the `immutable` field to `true`. For example: diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index cf76ed3f3f..48e3cc4cb6 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -55,18 +55,75 @@ See [Information security for Secrets](#information-security-for-secrets) for mo ## Uses for Secrets -There are three main ways for a Pod to use a Secret: +You can use Secrets for purposes such as the following: -- As [files](#using-secrets-as-files-from-a-pod) in a - {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of - its containers. -- As [container environment variable](#using-secrets-as-environment-variables). -- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. +- [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). +- [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds). +- [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/). The Kubernetes control plane also uses Secrets; for example, [bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to help automate node registration. +### Use case: dotfiles in a secret volume + +You can make your data "hidden" by defining a key that begins with a dot. +This key represents a dotfile or "hidden" file. For example, when the following secret +is mounted into a volume, `secret-volume`, the volume will contain a single file, +called `.secret-file`, and the `dotfile-test-container` will have this file +present at the path `/etc/secret-volume/.secret-file`. + +{{< note >}} +Files beginning with dot characters are hidden from the output of `ls -l`; +you must use `ls -la` to see them when listing directory contents. +{{< /note >}} + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: registry.k8s.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +### Use case: Secret visible to one container in a Pod + +Consider a program that needs to handle HTTP requests, do some complex business +logic, and then sign some messages with an HMAC. Because it has complex +application logic, there might be an unnoticed remote file reading exploit in +the server, which could expose the private key to an attacker. + +This could be divided into two processes in two containers: a frontend container +which handles user interaction and business logic, but which cannot see the +private key; and a signer container that can see the private key, and responds +to simple signing requests from the frontend (for example, over localhost networking). + +With this partitioned approach, an attacker now has to trick the application +server into doing something rather arbitrary, which may be harder than getting +it to read a file. + ### Alternatives to Secrets Rather than using a Secret to protect confidential data, you can pick from alternatives. @@ -108,8 +165,8 @@ These types vary in terms of the validations performed and the constraints Kubernetes imposes on them. | Built-in Type | Usage | -| ------------------------------------- | --------------------------------------- | -| `Opaque` | arbitrary user-defined data | +| ------------------------------------- |---------------------------------------- | +| `Opaque` | arbitrary user-defined data | | `kubernetes.io/service-account-token` | ServiceAccount token | | `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file | | `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file | @@ -576,17 +633,17 @@ metadata: name: mypod spec: containers: - - name: mypod - image: redis - volumeMounts: - - name: foo - mountPath: "/etc/foo" - readOnly: true - volumes: + - name: mypod + image: redis + volumeMounts: - name: foo - secret: - secretName: mysecret - optional: true + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + optional: true ``` By default, Secrets are required. None of a Pod's containers will start until @@ -697,269 +754,6 @@ for a detailed explanation of that process. You cannot use ConfigMaps or Secrets with {{< glossary_tooltip text="static Pods" term_id="static-pod" >}}. -## Use cases - -### Use case: As container environment variables {#use-case-as-container-environment-variables} - -You can create a Secret and use it to -[set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). - -### Use case: Pod with SSH keys - -Create a Secret containing some SSH keys: - -```shell -kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub -``` - -The output is similar to: - -``` -secret "ssh-key-secret" created -``` - -You can also create a `kustomization.yaml` with a `secretGenerator` field containing ssh keys. - -{{< caution >}} -Think carefully before sending your own SSH keys: other users of the cluster may have access -to the Secret. - -You could instead create an SSH private key representing a service identity that you want to be -accessible to all the users with whom you share the Kubernetes cluster, and that you can revoke -if the credentials are compromised. -{{< /caution >}} - -Now you can create a Pod which references the secret with the SSH key and -consumes it in a volume: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: secret-test-pod - labels: - name: secret-test -spec: - volumes: - - name: secret-volume - secret: - secretName: ssh-key-secret - containers: - - name: ssh-test-container - image: mySshImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -``` - -When the container's command runs, the pieces of the key will be available in: - -``` -/etc/secret-volume/ssh-publickey -/etc/secret-volume/ssh-privatekey -``` - -The container is then free to use the secret data to establish an SSH connection. - -### Use case: Pods with prod / test credentials - -This example illustrates a Pod which consumes a secret containing production credentials and -another Pod which consumes a secret with test environment credentials. - -You can create a `kustomization.yaml` with a `secretGenerator` field or run -`kubectl create secret`. - -```shell -kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 -``` - -The output is similar to: - -``` -secret "prod-db-secret" created -``` - -You can also create a secret for test environment credentials. - -```shell -kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests -``` - -The output is similar to: - -``` -secret "test-db-secret" created -``` - -{{< note >}} -Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your -[shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. - -In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). -For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command this way: - -```shell -kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' -``` - -You do not need to escape special characters in passwords from files (`--from-file`). -{{< /note >}} - -Now make the Pods: - -```shell -cat < pod.yaml -apiVersion: v1 -kind: List -items: -- kind: Pod - apiVersion: v1 - metadata: - name: prod-db-client-pod - labels: - name: prod-db-client - spec: - volumes: - - name: secret-volume - secret: - secretName: prod-db-secret - containers: - - name: db-client-container - image: myClientImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -- kind: Pod - apiVersion: v1 - metadata: - name: test-db-client-pod - labels: - name: test-db-client - spec: - volumes: - - name: secret-volume - secret: - secretName: test-db-secret - containers: - - name: db-client-container - image: myClientImage - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -EOF -``` - -Add the pods to the same `kustomization.yaml`: - -```shell -cat <> kustomization.yaml -resources: -- pod.yaml -EOF -``` - -Apply all those objects on the API server by running: - -```shell -kubectl apply -k . -``` - -Both containers will have the following files present on their filesystems with the values -for each container's environment: - -``` -/etc/secret-volume/username -/etc/secret-volume/password -``` - -Note how the specs for the two Pods differ only in one field; this facilitates -creating Pods with different capabilities from a common Pod template. - -You could further simplify the base Pod specification by using two service accounts: - -1. `prod-user` with the `prod-db-secret` -1. `test-user` with the `test-db-secret` - -The Pod specification is shortened to: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: prod-db-client-pod - labels: - name: prod-db-client -spec: - serviceAccount: prod-db-client - containers: - - name: db-client-container - image: myClientImage -``` - -### Use case: dotfiles in a secret volume - -You can make your data "hidden" by defining a key that begins with a dot. -This key represents a dotfile or "hidden" file. For example, when the following secret -is mounted into a volume, `secret-volume`: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: dotfile-secret -data: - .secret-file: dmFsdWUtMg0KDQo= ---- -apiVersion: v1 -kind: Pod -metadata: - name: secret-dotfiles-pod -spec: - volumes: - - name: secret-volume - secret: - secretName: dotfile-secret - containers: - - name: dotfile-test-container - image: registry.k8s.io/busybox - command: - - ls - - "-l" - - "/etc/secret-volume" - volumeMounts: - - name: secret-volume - readOnly: true - mountPath: "/etc/secret-volume" -``` - -The volume will contain a single file, called `.secret-file`, and -the `dotfile-test-container` will have this file present at the path -`/etc/secret-volume/.secret-file`. - -{{< note >}} -Files beginning with dot characters are hidden from the output of `ls -l`; -you must use `ls -la` to see them when listing directory contents. -{{< /note >}} - -### Use case: Secret visible to one container in a Pod - -Consider a program that needs to handle HTTP requests, do some complex business -logic, and then sign some messages with an HMAC. Because it has complex -application logic, there might be an unnoticed remote file reading exploit in -the server, which could expose the private key to an attacker. - -This could be divided into two processes in two containers: a frontend container -which handles user interaction and business logic, but which cannot see the -private key; and a signer container that can see the private key, and responds -to simple signing requests from the frontend (for example, over localhost networking). - -With this partitioned approach, an attacker now has to trick the application -server into doing something rather arbitrary, which may be harder than getting -it to read a file. - ## Immutable Secrets {#secret-immutable} {{< feature-state for_k8s_version="v1.21" state="stable" >}} diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 6dacf58ba5..1d0bfcb67a 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -340,12 +340,8 @@ namespaces based on their labels. ## Targeting a Namespace by its name -{{< feature-state for_k8s_version="1.22" state="stable" >}} - The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all -namespaces, provided that the `NamespaceDefaultLabelName` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. -The value of the label is the namespace name. +namespaces, the value of the label is the namespace name. While NetworkPolicy cannot target a namespace by its name with some object field, you can use the standardized label to target a specific namespace. diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md index 34d8618ece..3cd9c86622 100644 --- a/content/en/docs/concepts/storage/ephemeral-volumes.md +++ b/content/en/docs/concepts/storage/ephemeral-volumes.md @@ -248,11 +248,10 @@ same namespace, so that these conflicts can't occur. ### Security -Enabling the GenericEphemeralVolume feature allows users to create -PVCs indirectly if they can create Pods, even if they do not have -permission to create PVCs directly. Cluster administrators must be -aware of this. If this does not fit their security model, they should -use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) +Using generic ephemeral volumes allows users to create PVCs indirectly +if they can create Pods, even if they do not have permission to create PVCs directly. +Cluster administrators must be aware of this. If this does not fit their security model, +they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) that rejects objects like Pods that have a generic ephemeral volume. The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index 705d7bbaa6..48d48b81f4 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -74,10 +74,10 @@ used for provisioning VolumeSnapshots. This field must be specified. ### DeletionPolicy -Volume snapshot classes have a deletionPolicy. It enables you to configure what -happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to -is to be deleted. The deletionPolicy of a volume snapshot class can either be -`Retain` or `Delete`. This field must be specified. +Volume snapshot classes have a [deletionPolicy](/docs/concepts/storage/volume-snapshots/#delete). +It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot +object it is bound to is to be deleted. The deletionPolicy of a volume snapshot class can +either be `Retain` or `Delete`. This field must be specified. If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index da0e60050c..2948620fd0 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1061,7 +1061,7 @@ persistent volume: `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is optional, and may be empty if no secret is required. If the Secret contains more than one secret, all secrets are passed. -`nodeExpandSecretRef`: A reference to the secret containing sensitive +* `nodeExpandSecretRef`: A reference to the secret containing sensitive information to pass to the CSI driver to complete the CSI `NodeExpandVolume` call. This field is optional, and may be empty if no secret is required. If the object contains more than one secret, all @@ -1116,8 +1116,8 @@ For more information on how to develop a CSI driver, refer to the CSI node plugins need to perform various privileged operations like scanning of disk devices and mounting of file systems. These operations -differ for each host operating system. For Linux worker nodes, containerized CSI node -node plugins are typically deployed as privileged containers. For Windows worker nodes, +differ for each host operating system. For Linux worker nodes, containerized CSI node +plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 2ccbaefdb1..9becd24b7b 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -831,32 +831,12 @@ mismatch. {{< feature-state for_k8s_version="v1.26" state="stable" >}} -{{< note >}} -The control plane doesn't track Jobs using finalizers, if the Jobs were created -when the feature gate `JobTrackingWithFinalizers` was disabled, even after you -upgrade the control plane to 1.26. -{{< /note >}} - The control plane keeps track of the Pods that belong to any Job and notices if any such Pod is removed from the API server. To do that, the Job controller creates Pods with the finalizer `batch.kubernetes.io/job-tracking`. The controller removes the finalizer only after the Pod has been accounted for in the Job status, allowing the Pod to be removed by other controllers or users. -Jobs created before upgrading to Kubernetes 1.26 or before the feature gate -`JobTrackingWithFinalizers` is enabled are tracked without the use of Pod -finalizers. -The Job {{< glossary_tooltip term_id="controller" text="controller" >}} updates -the status counters for `succeeded` and `failed` Pods based only on the Pods -that exist in the cluster. The contol plane can lose track of the progress of -the Job if Pods are deleted from the cluster. - -You can determine if the control plane is tracking a Job using Pod finalizers by -checking if the Job has the annotation -`batch.kubernetes.io/job-tracking`. You should **not** manually add or remove -this annotation from Jobs. Instead, you can recreate the Jobs to ensure they -are tracked using Pod finalizers. - ### Elastic Indexed Jobs {{< feature-state for_k8s_version="v1.27" state="beta" >}} diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index f9367dd0c5..63c87dc25f 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -651,6 +651,12 @@ You can remove ... | You can easily remove ... These steps ... | These simple steps ... {{< /table >}} +### EditorConfig file +The Kubernetes project maintains an EditorConfig file that sets common style preferences in text editors +such as VS Code. You can use this file if you want to ensure that your contributions are consistent with +the rest of the project. To view the file, refer to +[`.editorconfig`](https://github.com/kubernetes/website/blob/main/.editorconfig) in the repository root. + ## {{% heading "whatsnext" %}} * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md index 5504f6070e..2e7fd8319d 100644 --- a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md @@ -218,7 +218,7 @@ configuration types to be used during a kubeadm init run.

pathType: File scheduler: extraArgs: - address: "10.100.0.1" + bind-address: "10.100.0.1" extraVolumes: - name: "some-volume" hostPath: "/etc/some-path" diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index 63114d9fbc..b2c0ec9aec 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -1094,17 +1094,10 @@ Example: `batch.kubernetes.io/job-tracking: ""` Used on: Jobs -The presence of this annotation on a Job indicates that the control plane is +The presence of this annotation on a Job used to indicate that the control plane is [tracking the Job status using finalizers](/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers). -The control plane uses this annotation to safely transition to tracking Jobs -using finalizers, while the feature is in development. -You should **not** manually add or remove this annotation. - -{{< note >}} -Starting from Kubernetes 1.26, this annotation is deprecated. -Kubernetes 1.27 and newer will ignore this annotation and always track Jobs -using finalizers. -{{< /note >}} +Adding or removing this annotation no longer has an effect (Kubernetes v1.27 and later) +All Jobs are tracked with finalizers. ### job-name (deprecated) {#job-name} diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md index 984172fadf..144352fbb0 100644 --- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -112,12 +112,14 @@ Here is a configuration file you can use to create a Pod: ``` Output: + ``` NAME READY STATUS RESTARTS AGE secret-test-pod 1/1 Running 0 42m ``` 1. Get a shell into the Container that is running in your Pod: + ```shell kubectl exec -i -t secret-test-pod -- /bin/bash ``` @@ -126,22 +128,28 @@ Here is a configuration file you can use to create a Pod: `/etc/secret-volume`. In your shell, list the files in the `/etc/secret-volume` directory: + ```shell # Run this in the shell inside the container ls /etc/secret-volume ``` + The output shows two files, one for each piece of secret data: + ``` password username ``` 1. In your shell, display the contents of the `username` and `password` files: + ```shell # Run this in the shell inside the container echo "$( cat /etc/secret-volume/username )" echo "$( cat /etc/secret-volume/password )" ``` + The output is your username and password: + ``` my-app 39528$vdg7Jb @@ -153,8 +161,8 @@ in this directory. ### Project Secret keys to specific file paths -You can also control the paths within the volume where Secret keys are projected. Use the `.spec.volumes[].secret.items` field to change the target -path of each key: +You can also control the paths within the volume where Secret keys are projected. Use the +`.spec.volumes[].secret.items` field to change the target path of each key: ```yaml apiVersion: v1 @@ -260,13 +268,14 @@ secrets change. kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml ``` -- In your shell, display the content of `SECRET_USERNAME` container environment variable +- In your shell, display the content of `SECRET_USERNAME` container environment variable. ```shell kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' ``` - The output is + The output is similar to: + ``` backend-admin ``` @@ -290,12 +299,14 @@ secrets change. kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml ``` -- In your shell, display the container environment variables +- In your shell, display the container environment variables. ```shell kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' ``` - The output is + + The output is similar to: + ``` DB_USERNAME=db-admin BACKEND_USERNAME=backend-admin @@ -313,7 +324,8 @@ This functionality is available in Kubernetes v1.6 and later. kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' ``` -- Use envFrom to define all of the Secret's data as container environment variables. The key from the Secret becomes the environment variable name in the Pod. +- Use envFrom to define all of the Secret's data as container environment variables. + The key from the Secret becomes the environment variable name in the Pod. {{% code file="pods/inject/pod-secret-envFrom.yaml" %}} @@ -323,18 +335,148 @@ This functionality is available in Kubernetes v1.6 and later. kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml ``` -- In your shell, display `username` and `password` container environment variables +- In your shell, display `username` and `password` container environment variables. ```shell kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' ``` - The output is + The output is similar to: + ``` username: my-app password: 39528$vdg7Jb ``` +## Example: Provide prod/test credentials to Pods using Secrets {#provide-prod-test-creds} + +This example illustrates a Pod which consumes a secret containing production credentials and +another Pod which consumes a secret with test environment credentials. + +1. Create a secret for prod environment credentials: + + ```shell + kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 + ``` + + The output is similar to: + + ``` + secret "prod-db-secret" created + ``` + +1. Create a secret for test environment credentials. + + ```shell + kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests + ``` + + The output is similar to: + + ``` + secret "test-db-secret" created + ``` + + {{< note >}} + Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your + [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. + + In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). + For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command as follows: + + ```shell + kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' + ``` + + You do not need to escape special characters in passwords from files (`--from-file`). + {{< /note >}} + +1. Create the Pod manifests: + + ```shell + cat < pod.yaml + apiVersion: v1 + kind: List + items: + - kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" + - kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" + EOF + ``` + + {{< note >}} + How the specs for the two Pods differ only in one field; this facilitates creating Pods + with different capabilities from a common Pod template. + {{< /note >}} + +1. Apply all those objects on the API server by running: + + ```shell + kubectl create -f pod.yaml + ``` + +Both containers will have the following files present on their filesystems with the values +for each container's environment: + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + +You could further simplify the base Pod specification by using two service accounts: + +1. `prod-user` with the `prod-db-secret` +1. `test-user` with the `test-db-secret` + +The Pod specification is shortened to: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + ### References - [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 956252b7d2..4fbe4f2d70 100644 --- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -154,7 +154,7 @@ description: |-

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

To see the output of our application, run a curl request:

-

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

+

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

The URL is the route to the API of the Pod.

diff --git a/content/en/docs/tutorials/services/pods-and-endpoint-termination-flow.md b/content/en/docs/tutorials/services/pods-and-endpoint-termination-flow.md index 6ae263556f..d056b62e53 100644 --- a/content/en/docs/tutorials/services/pods-and-endpoint-termination-flow.md +++ b/content/en/docs/tutorials/services/pods-and-endpoint-termination-flow.md @@ -38,53 +38,13 @@ Let's say you have a Deployment containing of a single `nginx` replica {{% code file="service/pod-with-graceful-termination.yaml" %}} -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: nginx-deployment - labels: - app: nginx -spec: - replicas: 1 - selector: - matchLabels: - app: nginx - template: - metadata: - labels: - app: nginx - spec: - terminationGracePeriodSeconds: 120 # extra long grace period - containers: - - name: nginx - image: nginx:latest - ports: - - containerPort: 80 - lifecycle: - preStop: - exec: - # Real life termination may take any time up to terminationGracePeriodSeconds. - # In this example - just hang around for at least the duration of terminationGracePeriodSeconds, - # at 120 seconds container will be forcibly terminated. - # Note, all this time nginx will keep processing requests. - command: [ - "/bin/sh", "-c", "sleep 180" - ] +{{% code file="service/explore-graceful-termination-nginx.yaml" %}} ---- +Now create the Deployment Pod and Service using the above files: -apiVersion: v1 -kind: Service -metadata: - name: nginx-service -spec: - selector: - app: nginx - ports: - - protocol: TCP - port: 80 - targetPort: 80 +```shell +kubectl apply -f pod-with-graceful-termination.yaml +kubectl apply -f explore-graceful-termination-nginx.yaml ``` Once the Pod and Service are running, you can get the name of any associated EndpointSlices: diff --git a/content/en/examples/service/explore-graceful-termination-nginx.yaml b/content/en/examples/service/explore-graceful-termination-nginx.yaml new file mode 100644 index 0000000000..6d1f97a64d --- /dev/null +++ b/content/en/examples/service/explore-graceful-termination-nginx.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app: nginx + ports: + - protocol: TCP + port: 80 + targetPort: 80 \ No newline at end of file diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index fd04ed816e..ea9e712552 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,8 +78,15 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| August 2023 | 2023-08-04 | 2023-08-09 | +| August 2023 | 2023-08-04 | 2023-08-23 | | September 2023 | 2023-09-08 | 2023-09-13 | +| October 2023 | 2023-10-13 | 2023-10-18 | +| November 2023 | N/A | N/A | +| December 2023 | 2023-12-01 | 2023-12-06 | + +**Note:** Due to overlap with KubeCon NA 2023 and lack of availability of +Release Managers and Google Build Admins, it has been decided to skip patch +releases in November. Instead, we'll have patch releases early in December. ## Detailed Release History for Active Branches diff --git a/content/fr/docs/concepts/cluster-administration/logging.md b/content/fr/docs/concepts/cluster-administration/logging.md index 0932de7406..52bcd88dff 100644 --- a/content/fr/docs/concepts/cluster-administration/logging.md +++ b/content/fr/docs/concepts/cluster-administration/logging.md @@ -50,7 +50,7 @@ d'évènements avec le flux de sortie standard. Cette démonstration utilise un manifeste pour un Pod avec un seul conteneur qui écrit du texte sur le flux de sortie standard toutes les secondes. -{{< codenew file="debug/counter-pod.yaml" >}} +{{% codenew file="debug/counter-pod.yaml" %}} Pour lancer ce Pod, utilisez la commande suivante : @@ -243,7 +243,7 @@ Un Pod exécute un unique conteneur et ce conteneur écrit dans deux fichiers de journaux différents en utilisant deux format différents. Voici le manifeste du Pod : -{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} +{{% codenew file="admin/logging/two-files-counter-pod.yaml" %}} Il serait très désordonné d'avoir des évènements avec des formats différents dans le même journal en redirigeant les évènements dans le flux de sortie @@ -253,8 +253,7 @@ suit un des fichiers et renvoie les évènements sur son propre `stdout`. Ci-dessous se trouve le manifeste pour un Pod avec deux conteneurs side-car. -{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" ->}} +{{% codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}} Quand ce Pod s'exécute, chaque journal peut être diffusé séparément en utilisant les commandes suivantes : @@ -323,7 +322,7 @@ Le premier fichier contient un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) pour configurer fluentd. -{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} +{{% codenew file="admin/logging/fluentd-sidecar-config.yaml" %}} {{< note >}} La configuration de fluentd est hors du cadre de cet article. Vous trouverez @@ -335,7 +334,7 @@ Le second fichier est un manifeste pour un Pod avec un conteneur side-car qui exécute fluentd. Le Pod monte un volume où fluentd peut récupérer sa configuration. -{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} +{{% codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}} Apres quelques minutes, les évènements apparaîtront dans l'interface de Stackdriver. diff --git a/content/fr/docs/concepts/services-networking/ingress.md b/content/fr/docs/concepts/services-networking/ingress.md index f7a1f0c240..140b15715d 100644 --- a/content/fr/docs/concepts/services-networking/ingress.md +++ b/content/fr/docs/concepts/services-networking/ingress.md @@ -330,7 +330,7 @@ type: kubernetes.io/tls Référencer ce secret dans un Ingress indiquera au contrôleur d'Ingress de sécuriser le canal du client au load-balancer à l'aide de TLS. Vous devez vous assurer que le secret TLS que vous avez créé provenait d'un certificat contenant un Common Name (CN), aussi appelé nom de domaine pleinement qualifié (FQDN), pour `https-example.foo.com`. -{{< codenew file="service/networking/tls-example-ingress.yaml" >}} +{{% codenew file="service/networking/tls-example-ingress.yaml" %}} {{< note >}} diff --git a/content/fr/docs/concepts/workloads/controllers/deployment.md b/content/fr/docs/concepts/workloads/controllers/deployment.md index d4df1e33b9..76d4c62cc6 100644 --- a/content/fr/docs/concepts/workloads/controllers/deployment.md +++ b/content/fr/docs/concepts/workloads/controllers/deployment.md @@ -49,7 +49,7 @@ Voici des cas d'utilisation typiques pour les déploiements: Voici un exemple de déploiement. Il crée un ReplicaSet pour faire apparaître trois pods `nginx`: -{{< codenew file="controllers/nginx-deployment.yaml" >}} +{{% codenew file="controllers/nginx-deployment.yaml" %}} Dans cet exemple: diff --git a/content/fr/docs/concepts/workloads/controllers/replicaset.md b/content/fr/docs/concepts/workloads/controllers/replicaset.md index 3204d35277..9730600898 100644 --- a/content/fr/docs/concepts/workloads/controllers/replicaset.md +++ b/content/fr/docs/concepts/workloads/controllers/replicaset.md @@ -41,7 +41,7 @@ utilisez plutôt un déploiement et définissez votre application dans la sectio ## Exemple -{{< codenew file="controllers/frontend.yaml" >}} +{{% codenew file="controllers/frontend.yaml" %}} Enregistrer ce manifeste dans `frontend.yaml` et le soumettre à un cluster Kubernetes va créer le ReplicaSet défini et les pods qu’il gère. @@ -145,7 +145,7 @@ labels correspondant au sélecteur de l’un de vos ReplicaSets. Car un ReplicaS Prenez l'exemple précédent de ReplicaSet, ainsi que les pods spécifiés dans le manifeste suivant : -{{< codenew file="pods/pod-rs.yaml" >}} +{{% codenew file="pods/pod-rs.yaml" %}} Ces pods n’ayant pas de contrôleur (ni d’objet) en tant que référence propriétaire, ils correspondent au sélecteur de du ReplicaSet frontend, ils seront donc immédiatement acquis par ce ReplicaSet. @@ -291,7 +291,7 @@ Un ReplicaSet peut également être une cible pour Un ReplicaSet peut être mis à l'échelle automatiquement par un HPA. Voici un exemple HPA qui cible le ReplicaSet que nous avons créé dans l'exemple précédent. -{{< codenew file="controllers/hpa-rs.yaml" >}} +{{% codenew file="controllers/hpa-rs.yaml" %}} Enregistrer ce manifeste dans `hpa-rs.yaml` et le soumettre à un cluster Kubernetes devrait créer le HPA défini qui scale automatiquement le ReplicaSet cible en fonction de l'utilisation du processeur diff --git a/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index ea326f5c11..9fa8eec4a9 100644 --- a/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/fr/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -95,7 +95,7 @@ Supposons que vous ayez un cluster de 4 noeuds où 3 Pods étiquettés `foo:bar` Si nous voulons qu'un nouveau Pod soit uniformément réparti avec les Pods existants à travers les zones, la spec peut être : -{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} +{{% codenew file="pods/topology-spread-constraints/one-constraint.yaml" %}} `topologyKey: zone` implique que la distribution uniforme sera uniquement appliquée pour les noeuds ayant le label "zone:<any value>" présent. `whenUnsatisfiable: DoNotSchedule` indique au scheduler de laisser le Pod dans l'état Pending si le Pod entrant ne peut pas satisfaire la contrainte. @@ -133,7 +133,7 @@ Cela s'appuie sur l'exemple précédent. Supposons que vous ayez un cluster de 4 Vous pouvez utiliser 2 TopologySpreadConstraints pour contrôler la répartition des Pods aussi bien dans les zones que dans les noeuds : -{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} +{{% codenew file="pods/topology-spread-constraints/two-constraints.yaml" %}} Dans ce cas, pour satisfaire la première contrainte, le Pod entrant peut uniquement être placé dans "zoneB" ; alors que pour satisfaire la seconde contrainte, le Pod entrant peut uniquement être placé dans "node4". Le résultat étant l'intersection des résultats des 2 contraintes, l'unique option possible est de placer le Pod entrant dans "node4". @@ -182,7 +182,7 @@ Il existe quelques conventions implicites qu'il est intéressant de noter ici : et vous savez que "zoneC" doit être exclue. Dans ce cas, vous pouvez écrire le yaml ci-dessous, pour que "mypod" soit placé dans "zoneB" plutôt que dans "zoneC". `spec.nodeSelector` est pris en compte de la même manière. - {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} + {{% codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" %}} ### Contraintes par défaut au niveau du cluster diff --git a/content/fr/docs/contribute/style/write-new-topic.md b/content/fr/docs/contribute/style/write-new-topic.md index 1027da53b6..d7780747dc 100644 --- a/content/fr/docs/contribute/style/write-new-topic.md +++ b/content/fr/docs/contribute/style/write-new-topic.md @@ -108,13 +108,14 @@ Utilisez cette méthode pour inclure des exemples de fichiers YAML lorsque l'éc Lors de l'ajout d'un nouveau fichier d'exemple autonome, tel qu'un fichier YAML, placez le code dans l'un des sous-répertoires `/examples/` où `` est la langue utilisé dans votre page. Dans votre fichier, utilisez le shortcode `codenew` : -
{{< codenew file="<RELPATH>/my-example-yaml>" >}}
- +```none +{{%/* codenew file="/my-example-yaml>" */%}} +``` où `` est le chemin vers le fichier à inclure, relatif au répertoire `examples`. Le shortcode Hugo suivant fait référence à un fichier YAML situé sur `/content/en/examples/pods/storage/gce-volume.yaml`. ```none -{{}} +{{%/* codenew file="pods/storage/gce-volume.yaml" */%}} ``` {{< note >}} diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index afb0b266e5..be9206a015 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -1228,7 +1228,7 @@ comprend des recommandations pour restreindre cet accès dans les clusters exist Si vous souhaitez que les nouveaux clusters conservent ce niveau d'accès dans les rôles agrégés, vous pouvez créer le ClusterRole suivant : -{{< codenew file="access/endpoints-aggregated.yaml" >}} +{{% codenew file="access/endpoints-aggregated.yaml" %}} ## Mise à niveau à partir d'ABAC diff --git a/content/fr/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/fr/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 1016696111..a3165ab992 100644 --- a/content/fr/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/fr/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -33,7 +33,7 @@ Si votre environnement ne prend pas en charge cette fonction, vous pouvez utilis Le backend est un simple microservice de salutations. Voici le fichier de configuration pour le Deployment backend : -{{< codenew file="service/access/backend-deployment.yaml" >}} +{{% codenew file="service/access/backend-deployment.yaml" %}} Créez le Deployment backend : @@ -91,7 +91,7 @@ Un Service utilise des {{< glossary_tooltip text="sélecteurs" term_id="selector Tout d'abord, explorez le fichier de configuration du Service : -{{< codenew file="service/access/backend-service.yaml" >}} +{{% codenew file="service/access/backend-service.yaml" %}} Dans le fichier de configuration, vous pouvez voir que le Service, nommé `hello`, achemine le trafic vers les Pods ayant les labels `app: hello` et `tier: backend`. @@ -120,16 +120,16 @@ Les Pods du frontend Deployment exécutent une image nginx configurée pour acheminer les requêtes vers le Service backend `hello`. Voici le fichier de configuration nginx : -{{< codenew file="service/access/frontend-nginx.conf" >}} +{{% codenew file="service/access/frontend-nginx.conf" %}} Comme pour le backend, le frontend dispose d'un Deployment et d'un Service. Une différence importante à noter entre les services backend et frontend est que le Service frontend est configuré avec un `type: LoadBalancer`, ce qui signifie que le Service utilise un équilibreur de charge provisionné par votre fournisseur de cloud et sera accessible depuis l'extérieur du cluster. -{{< codenew file="service/access/frontend-service.yaml" >}} +{{% codenew file="service/access/frontend-service.yaml" %}} -{{< codenew file="service/access/frontend-deployment.yaml" >}} +{{% codenew file="service/access/frontend-deployment.yaml" %}} Créez le Deployment et le Service frontend : diff --git a/content/fr/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/fr/docs/tasks/access-application-cluster/service-access-application-cluster.md index 4d15999ab3..b24d0b1da6 100644 --- a/content/fr/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/fr/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -27,7 +27,7 @@ ayant deux instances en cours d'exécution. Voici le fichier de configuration pour le déploiement de l'application : -{{< codenew file="service/access/hello-application.yaml" >}} +{{% codenew file="service/access/hello-application.yaml" %}} 1. Exécutez une application Hello World dans votre cluster : Créez le déploiement de l'application en utilisant le fichier ci-dessus : diff --git a/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md b/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md index d2e9a02420..581a7043ad 100644 --- a/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md @@ -74,7 +74,7 @@ Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouv Pour les fournisseurs qui se trouvent déjà dans Kubernetes, vous pouvez exécuter le cloud-controller-manager dans l'arborescence en tant que Daemonset dans votre cluster. Utilisez ce qui suit comme guide: -{{< codenew file="admin/cloud/ccm-example.yaml" >}} +{{% codenew file="admin/cloud/ccm-example.yaml" %}} ## Limitations diff --git a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md index 2d9af18838..8908405f09 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -64,7 +64,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de CPU Dans cet exercice, vous allez créer un Pod qui a un seul conteneur. Le conteneur a une demande de 0.5 CPU et une limite de 1 CPU. Voici le fichier de configuration du Pod : -{{< codenew file="pods/resource/cpu-request-limit.yaml" >}} +{{% codenew file="pods/resource/cpu-request-limit.yaml" %}} La section `args` du fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre. L'argument `-cpus "2"` demande au conteneur d'utiliser 2 CPUs. @@ -147,7 +147,7 @@ L'ordonnancement des pods est basé sur les demandes. Un Pod est prévu pour se Dans cet exercice, vous allez créer un Pod qui a une demande de CPU si importante qu'elle dépassera la capacité de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur nécessite 100 CPU, ce qui est susceptible de dépasser la capacité de tous les nœuds de votre cluster. -{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}} +{{% codenew file="pods/resource/cpu-request-limit-2.yaml" %}} Créez le Pod : diff --git a/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md index 754e91972b..fce76eca88 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -60,7 +60,7 @@ dans le manifeste des ressources du conteneur. Pour spécifier une limite de mé Dans cet exercice, vous créez un pod qui possède un seul conteneur. Le conteneur dispose d'une demande de mémoire de 100 MiB et une limite de mémoire de 200 MiB. Voici le fichier de configuration pour le Pod : -{{< codenew file="pods/resource/memory-request-limit.yaml" >}} +{{% codenew file="pods/resource/memory-request-limit.yaml" %}} La section `args` de votre fichier de configuration fournit des arguments pour le conteneur lorsqu'il démarre. Les arguments `"--vm-bytes", "150M"` indiquent au conteneur d'allouer 150 MiB de mémoire. @@ -123,7 +123,7 @@ Si un conteneur terminé peut être redémarré, le kubelet le redémarre, comme Dans cet exercice, vous créez un Pod qui tente d'allouer plus de mémoire que sa limite. Voici le fichier de configuration d'un Pod qui contient un conteneur avec une demande de mémoire de 50 MiB et une limite de mémoire de 100 MiB : -{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} +{{% codenew file="pods/resource/memory-request-limit-2.yaml" %}} Dans la section `args` du fichier de configuration, vous pouvez voir que le conteneur tentera d'allouer 250 MiB de mémoire, ce qui est bien au-dessus de la limite de 100 MiB. @@ -226,7 +226,7 @@ L'ordonnancement des modules est basé sur les demandes. Un Pod est schedulé po Dans cet exercice, vous allez créer un Pod dont la demande de mémoire est si importante qu'elle dépasse la capacité de la mémoire de n'importe quel nœud de votre cluster. Voici le fichier de configuration d'un Pod qui possède un seul conteneur avec une demande de 1000 GiB de mémoire, qui dépasse probablement la capacité de tous les nœuds de votre cluster. -{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} +{{% codenew file="pods/resource/memory-request-limit-3.yaml" %}} Créez le Pod : diff --git a/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md index 3b102eee1f..be49ecd78b 100644 --- a/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -62,7 +62,7 @@ Cette page montre comment assigner un Pod à un nœud particulier dans un cluste Le fichier de configuration de pod décrit un pod qui possède un selector de nœud de type `disktype:ssd`. Cela signifie que le pod sera planifié sur un nœud ayant le label `disktype=ssd`. -{{< codenew file="pods/pod-nginx.yaml" >}} +{{% codenew file="pods/pod-nginx.yaml" %}} 1. Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur votre nœud choisi : @@ -86,7 +86,7 @@ Le fichier de configuration de pod décrit un pod qui possède un selector de n Vous pouvez également ordonnancer un pod sur un nœud spécifique via le paramètre `nodeName`. -{{< codenew file="pods/pod-nginx-specific-node.yaml" >}} +{{% codenew file="pods/pod-nginx-specific-node.yaml" %}} Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur `foo-node` uniquement. diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 39cf2ecbd4..3778d67924 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -29,7 +29,7 @@ De nombreuses applications fonctionnant pour des longues périodes finissent par Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image `registry.k8s.io/busybox`. Voici le fichier de configuration pour le Pod : -{{< codenew file="pods/probe/exec-liveness.yaml" >}} +{{% codenew file="pods/probe/exec-liveness.yaml" %}} Dans le fichier de configuration, vous constatez que le Pod a un seul conteneur. Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liveness toutes les 5 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 5 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet exécute la commande `cat /tmp/healthy` dans le conteneur. Si la commande réussit, elle renvoie 0, et le Kubelet considère que le conteneur est vivant et en bonne santé. Si la commande renvoie une valeur non nulle, le Kubelet tue le conteneur et le redémarre. @@ -104,7 +104,7 @@ liveness-exec 1/1 Running 1 1m Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/liveness`. -{{< codenew file="pods/probe/http-liveness.yaml" >}} +{{% codenew file="pods/probe/http-liveness.yaml" %}} Dans le fichier de configuration, vous pouvez voir que le Pod a un seul conteneur. Le champ `periodSeconds` spécifie que le Kubelet doit effectuer une liveness probe toutes les 3 secondes. Le champ `initialDelaySeconds` indique au Kubelet qu'il devrait attendre 3 secondes avant d'effectuer la première probe. Pour effectuer une probe, le Kubelet envoie une requête HTTP GET au serveur qui s'exécute dans le conteneur et écoute sur le port 8080. Si le handler du chemin `/healthz` du serveur renvoie un code de succès, le Kubelet considère que le conteneur est vivant et en bonne santé. Si le handler renvoie un code d'erreur, le Kubelet tue le conteneur et le redémarre. @@ -152,7 +152,7 @@ Dans les versions postérieures à la v1.13, les paramètres de la variable d'en Un troisième type de liveness probe utilise un TCP Socket. Avec cette configuration, le Kubelet tentera d'ouvrir un socket vers votre conteneur sur le port spécifié. S'il arrive à établir une connexion, le conteneur est considéré comme étant en bonne santé, s'il n'y arrive pas, c'est un échec. -{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} +{{% codenew file="pods/probe/tcp-liveness-readiness.yaml" %}} Comme vous le voyez, la configuration pour un check TCP est assez similaire à un check HTTP. Cet exemple utilise à la fois des readiness et liveness probes. Le Kubelet transmettra la première readiness probe 5 secondes après le démarrage du conteneur. Il tentera de se connecter au conteneur `goproxy` sur le port 8080. Si la probe réussit, le conteneur sera marqué comme prêt. Kubelet continuera à effectuer ce check tous les 10 secondes. diff --git a/content/fr/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/fr/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 75ae3c6846..4f4ae7fca4 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -75,7 +75,7 @@ pour paramétrer du [provisioning dynamique](/docs/concepts/storage/dynamic-provisioning/). Voici le fichier de configuration pour le PersistentVolume de type hostPath: -{{< codenew file="pods/storage/pv-volume.yaml" >}} +{{% codenew file="pods/storage/pv-volume.yaml" %}} Le fichier de configuration spécifie que le chemin du volume sur le noeud est `/mnt/data`. Il spécifie aussi une taille de 10 gibibytes, ainsi qu'un mode d'accès de type `ReadWriteOnce`, impliquant que le volume ne peut être monté en lecture et écriture que par un seul noeud. Le fichier définit un [nom de StorageClass](/docs/concepts/storage/persistent-volumes/#class) à `manual`, ce qui sera utilisé pour attacher un PersistentVolumeClaim à ce PersistentVolume @@ -103,7 +103,7 @@ La prochaine étape est de créer un PersistentVolumeClaim (demande de stockage) Dans cet exercice, vous créez un PersistentVolumeClaim qui demande un volume d'au moins 3 GB, et qui peut être monté en lecture et écriture sur au moins un noeud. Voici le fichier de configuration du PersistentVolumeClaim: -{{< codenew file="pods/storage/pv-claim.yaml" >}} +{{% codenew file="pods/storage/pv-claim.yaml" %}} Créez le PersistentVolumeClaim: @@ -137,7 +137,7 @@ La prochaine étape est de créer un Pod qui utilise le PersistentVolumeClaim co Voici le fichier de configuration du Pod: -{{< codenew file="pods/storage/pv-pod.yaml" >}} +{{% codenew file="pods/storage/pv-pod.yaml" %}} Notez que le fichier de configuration du Pod spécifie un PersistentVolumeClaim et non un PersistentVolume. Du point de vue du Pod, la demande est un volume de stockage. @@ -200,7 +200,7 @@ Vous pouvez maintenant arrêter la session shell vers votre noeud. Vous pouvez monter plusieurs fois un même PersistentVolume à plusieurs endroits différents dans votre container nginx: -{{< codenew file="pods/storage/pv-duplicate.yaml" >}} +{{% codenew file="pods/storage/pv-duplicate.yaml" %}} - `/usr/share/nginx/html` pour le site statique - `/etc/nginx/nginx.conf` pour la configuration par défaut diff --git a/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md index 6e9c4c5ba6..6fa439bdad 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -453,7 +453,7 @@ configmap/special-config-2-c92b5mmcf2 created 1. Attribuez la valeur `special.how` défini dans ConfigMap à la variable d'environnement `SPECIAL_LEVEL_KEY` dans la spécification du Pod. - {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}} + {{% codenew file="pods/pod-single-configmap-env-variable.yaml" %}} Créez le pod: @@ -467,7 +467,7 @@ configmap/special-config-2-c92b5mmcf2 created * Comme avec l'exemple précédent, créez d'abord les ConfigMaps. - {{< codenew file="configmap/configmaps.yaml" >}} + {{% codenew file="configmap/configmaps.yaml" %}} Créez le ConfigMap: @@ -477,7 +477,7 @@ configmap/special-config-2-c92b5mmcf2 created * Définissez les variables d'environnement dans la spécification Pod. - {{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}} + {{% codenew file="pods/pod-multiple-configmap-env-variable.yaml" %}} Créez le pod: @@ -495,7 +495,7 @@ Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieur * Créez un ConfigMap contenant plusieurs paires clé-valeur. - {{< codenew file="configmap/configmap-multikeys.yaml" >}} + {{% codenew file="configmap/configmap-multikeys.yaml" %}} Créez le ConfigMap: @@ -506,7 +506,7 @@ Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieur * Utilisez `envFrom` pour définir toutes les données du ConfigMap en tant que variables d'environnement du conteneur. La clé de ConfigMap devient le nom de la variable d'environnement dans le pod. - {{< codenew file="pods/pod-configmap-envFrom.yaml" >}} + {{% codenew file="pods/pod-configmap-envFrom.yaml" %}} Créez le pod: @@ -522,7 +522,7 @@ Vous pouvez utiliser des variables d'environnement définies par ConfigMap dans Par exemple, la spécification de pod suivante -{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}} +{{% codenew file="pods/pod-configmap-env-var-valueFrom.yaml" %}} créé en exécutant @@ -543,7 +543,7 @@ Le contenu du fichier devient la valeur de la clé. Les exemples de cette section se réfèrent à un ConfigMap nommé special-config, illustré ci-dessous. -{{< codenew file="configmap/configmap-multikeys.yaml" >}} +{{% codenew file="configmap/configmap-multikeys.yaml" %}} Créez le ConfigMap: @@ -557,7 +557,7 @@ Ajoutez le nom ConfigMap sous la section `volumes` de la spécification Pod. Ceci ajoute les données ConfigMap au répertoire spécifié comme `volumeMounts.mountPath` (dans ce cas, `/etc/config`). La section `command` répertorie les fichiers de répertoire dont les noms correspondent aux clés de ConfigMap. -{{< codenew file="pods/pod-configmap-volume.yaml" >}} +{{% codenew file="pods/pod-configmap-volume.yaml" %}} Créez le pod: @@ -581,7 +581,7 @@ S'il y a des fichiers dans le dossier `/etc/config/`, ils seront supprimés. Utilisez le champ `path` pour spécifier le chemin de fichier souhaité pour les éléments de configmap spécifiques. Dans ce cas, le `SPECIAL_LEVEL` sera monté dans le volume `config-volume` au chemin `/etc/config/keys`. -{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}} +{{% codenew file="pods/pod-configmap-volume-specific-key.yaml" %}} Créez le Pod : diff --git a/content/fr/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/fr/docs/tasks/configure-pod-container/configure-pod-initialization.md index eeb33a0d4b..7017ecbd68 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -24,7 +24,7 @@ Dans cet exercice, vous allez créer un Pod qui a un conteneur d'application et Voici le fichier de configuration du Pod : -{{< codenew file="pods/init-containers.yaml" >}} +{{% codenew file="pods/init-containers.yaml" %}} Dans le fichier de configuration, vous pouvez voir que le Pod a un Volume que le conteneur d'initialisation et le conteneur d'application partagent. diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index 4f38f3a397..f3b862a684 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -269,7 +269,7 @@ Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : -{{< codenew file="pods/pod-projected-svc-token.yaml" >}} +{{% codenew file="pods/pod-projected-svc-token.yaml" %}} Créez le Pod diff --git a/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md index 3c17aa3cda..7fdb1e4a54 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -29,7 +29,7 @@ Dans cet exercice, vous créez un pod qui contient un seul conteneur. Ce Pod a u [emptyDir](/fr/docs/concepts/storage/volumes/#emptydir) qui dure toute la vie du Pod, même si le conteneur se termine et redémarre. Voici le fichier de configuration du Pod : -{{< codenew file="pods/storage/redis.yaml" >}} +{{% codenew file="pods/storage/redis.yaml" %}} 1. Créez le Pod : diff --git a/content/fr/docs/tasks/configure-pod-container/extended-resource.md b/content/fr/docs/tasks/configure-pod-container/extended-resource.md index 439714f6fd..68a79a6073 100644 --- a/content/fr/docs/tasks/configure-pod-container/extended-resource.md +++ b/content/fr/docs/tasks/configure-pod-container/extended-resource.md @@ -34,7 +34,7 @@ Les noms de ressources supplémentaires valides ont la forme `example.com/foo` o Voici le fichier de configuration d'un Pod qui a un seul conteneur : -{{< codenew file="pods/resource/extended-resource-pod.yaml" >}} +{{% codenew file="pods/resource/extended-resource-pod.yaml" %}} Dans le fichier de configuration, vous pouvez constater que le conteneur demande 3 dongles. @@ -70,7 +70,7 @@ Requests: Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur demande deux dongles. -{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}} +{{% codenew file="pods/resource/extended-resource-pod-2.yaml" %}} Kubernetes ne pourra pas satisfaire la demande de deux dongles, parce que le premier Pod a utilisé trois des quatre dongles disponibles. diff --git a/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md index efe9ee74fa..c4917e5a21 100644 --- a/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/fr/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -170,7 +170,7 @@ Vous avez réussi à définir vos identifiants de Docker comme un Secret appelé Voici un fichier de configuration pour un Pod qui a besoin d'accéder à vos identifiants Docker dans `regcred` : -{{< codenew file="pods/private-reg-pod.yaml" >}} +{{% codenew file="pods/private-reg-pod.yaml" %}} Téléchargez le fichier ci-dessus : diff --git a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md index 93e785f54c..a8056b94a4 100644 --- a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md @@ -48,7 +48,7 @@ Pour qu'un Pod reçoive une classe de QoS Guaranteed : Ci-dessous le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur dispose d'une limite de mémoire et d'une demande de mémoire, tous deux égaux à 200 MiB. Le conteneur a également une limite CPU et une demande CPU, toutes deux égales à 700 milliCPU : -{{< codenew file="pods/qos/qos-pod.yaml" >}} +{{% codenew file="pods/qos/qos-pod.yaml" %}} Créez le Pod : @@ -99,7 +99,7 @@ Un Pod reçoit une classe QoS de Burstable si : Voici le fichier de configuration d'un pod qui a un seul conteneur. Le conteneur a une limite de mémoire de 200 MiB et une demande de mémoire de 100 MiB. -{{< codenew file="pods/qos/qos-pod-2.yaml" >}} +{{% codenew file="pods/qos/qos-pod-2.yaml" %}} Créez le Pod : @@ -143,7 +143,7 @@ avoir des limites ou des demandes de mémoire ou de CPU. Voici le fichier de configuration d'un Pod qui a un seul conteneur. Le conteneur n'a pas des limites ou des demandes de mémoire ou de CPU : -{{< codenew file="pods/qos/qos-pod-3.yaml" >}} +{{% codenew file="pods/qos/qos-pod-3.yaml" %}} Créez le Pod : @@ -181,7 +181,7 @@ kubectl delete pod qos-demo-3 --namespace=qos-example Voici le fichier de configuration d'un Pod qui a deux conteneurs. Un conteneur spécifie une demande de mémoire de 200 MiB. L'autre conteneur ne spécifie aucune demande ou limite. -{{< codenew file="pods/qos/qos-pod-4.yaml" >}} +{{% codenew file="pods/qos/qos-pod-4.yaml" %}} Notez que le pod répond aux critères de la classe QoS Burstable. En d'autres termes, il ne répond pas aux exigences de la classe de qualité de service Guaranteed, et l'un de ses conteneurs dispose d'une demande de mémoire. diff --git a/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md b/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md index cb5a99cbe3..5223490c6d 100644 --- a/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/fr/docs/tasks/configure-pod-container/share-process-namespace.md @@ -23,7 +23,7 @@ Vous pouvez utiliser cette fonctionnalité pour configurer les conteneurs coopé Le partage de l'espace de nommage du processus est activé en utilisant le champ `shareProcessNamespace` de `v1.PodSpec`. Par exemple: -{{< codenew file="pods/share-process-namespace.yaml" >}} +{{% codenew file="pods/share-process-namespace.yaml" %}} 1. Créez le pod `nginx` sur votre cluster : diff --git a/content/fr/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/fr/docs/tasks/debug-application-cluster/get-shell-running-container.md index b5fb0012a1..1973bcd1bb 100644 --- a/content/fr/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/fr/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -24,7 +24,7 @@ Dans cet exercice, vous allez créer un pod contenant un conteneur. Le conteneur exécute une image nginx. Voici le fichier de configuration du Pod: -{{< codenew file="application/shell-demo.yaml" >}} +{{% codenew file="application/shell-demo.yaml" %}} Créez le Pod: diff --git a/content/fr/docs/tasks/inject-data-application/define-command-argument-container.md b/content/fr/docs/tasks/inject-data-application/define-command-argument-container.md index bf55910e44..b36ad83d15 100644 --- a/content/fr/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/fr/docs/tasks/inject-data-application/define-command-argument-container.md @@ -38,7 +38,7 @@ Le champ `command` correspond à `entrypoint` dans certains runtimes de containe Dans cet exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration pour le Pod défini une commande ainsi que deux arguments: -{{< codenew file="pods/commands.yaml" >}} +{{% codenew file="pods/commands.yaml" %}} 1. Créez un Pod en utilisant le fichier YAML de configuration suivant: diff --git a/content/fr/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/fr/docs/tasks/inject-data-application/define-environment-variable-container.md index c55aa45ac5..357b1da5f0 100644 --- a/content/fr/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/fr/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -24,7 +24,7 @@ dans le fichier de configuration. Dans cet exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration pour ce Pod contient une variable d'environnement s'appelant `DEMO_GREETING` et sa valeur est `"Hello from the environment"`. Voici le fichier de configuration du Pod: -{{< codenew file="pods/inject/envars.yaml" >}} +{{% codenew file="pods/inject/envars.yaml" %}} 1. Créez un Pod à partir de ce fichier: diff --git a/content/fr/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/fr/docs/tasks/inject-data-application/define-interdependent-environment-variables.md index 73bf9afa94..b532e6e40e 100644 --- a/content/fr/docs/tasks/inject-data-application/define-interdependent-environment-variables.md +++ b/content/fr/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -25,7 +25,7 @@ Pour définir une variable d'environnement dépendante, vous pouvez utiliser le Dans cette exercice, vous allez créer un Pod qui exécute un container. Le fichier de configuration de ce Pod définit des variables d'environnement interdépendantes avec une ré-utilisation entre les différentes variables. Voici le fichier de configuration de ce Pod: -{{< codenew file="pods/inject/dependent-envars.yaml" >}} +{{% codenew file="pods/inject/dependent-envars.yaml" %}} 1. Créez un Pod en utilisant ce fichier de configuration: diff --git a/content/fr/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/fr/docs/tasks/inject-data-application/distribute-credentials-secure.md index f2052c52ff..2faf3caa83 100644 --- a/content/fr/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/fr/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -39,7 +39,7 @@ afin de réduire les risques de sécurité liés à l'utilisation d'un outil ext Voici un fichier de configuration que vous pouvez utiliser pour créer un Secret qui contiendra votre identifiant et mot de passe: -{{< codenew file="pods/inject/secret.yaml" >}} +{{% codenew file="pods/inject/secret.yaml" %}} 1. Créez le Secret: @@ -99,7 +99,7 @@ montrée précédemment permet de démontrer et comprendre le fonctionnement des Voici un fichier de configuration qui permet de créer un Pod: -{{< codenew file="pods/inject/secret-pod.yaml" >}} +{{% codenew file="pods/inject/secret-pod.yaml" %}} 1. Créez le Pod: @@ -255,7 +255,7 @@ permettant de redémarrer les containers lors d'une mise à jour du Secret. * Assignez la valeur de `backend-username` définie dans le Secret à la variable d'environnement `SECRET_USERNAME` dans la configuration du Pod. - {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}} + {{% codenew file="pods/inject/pod-single-secret-env-variable.yaml" %}} * Créez le Pod: @@ -286,7 +286,7 @@ permettant de redémarrer les containers lors d'une mise à jour du Secret. * Définissez les variables d'environnement dans la configuration du Pod. - {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}} + {{% codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" %}} * Créez le Pod: @@ -323,7 +323,7 @@ Cette fonctionnalité n'est disponible que dans les versions de Kubernetes d'environnement. Les clés du Secret deviendront les noms des variables d'environnement à l'intérieur du Pod. - {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} + {{% codenew file="pods/inject/pod-secret-envFrom.yaml" %}} * Créez le Pod: diff --git a/content/fr/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/fr/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index 764a0c24de..02e3cc332f 100644 --- a/content/fr/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/fr/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -35,7 +35,7 @@ et vous allez projeter les champs d'informations du Pod à l'intérieur du container via des fichiers dans le container. Voici le fichier de configuration du Pod: -{{< codenew file="pods/inject/dapi-volume.yaml" >}} +{{% codenew file="pods/inject/dapi-volume.yaml" %}} Dans la configuration, on peut voir que le Pod a un volume de type `downward API`, et que le container monte ce volume sur le chemin `/etc/podinfo`. @@ -154,7 +154,7 @@ qui appartiennent au [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container), plutôt qu'au Pod. Voici un fichier de configuration pour un Pod qui n'a qu'un seul container: -{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}} +{{% codenew file="pods/inject/dapi-volume-resources.yaml" %}} Dans cette configuration, on peut voir que le Pod a un volume de type [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi), diff --git a/content/fr/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/fr/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 06999676da..a44ce95370 100644 --- a/content/fr/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/fr/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -32,7 +32,7 @@ Dans cette partie de l'exercice, vous allez créer un Pod qui a un container, et vous allez projeter les champs d'informations du Pod à l'intérieur du container comme variables d'environnement. -{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} +{{% codenew file="pods/inject/dapi-envars-pod.yaml" %}} Dans ce fichier de configuration, on trouve cinq variables d'environnement. Le champ `env` est une liste de variables d'environnement. @@ -113,7 +113,7 @@ qui est exécuté à l'intérieur du Pod. Voici un fichier de configuration pour un autre Pod qui ne contient qu'un seul container: -{{< codenew file="pods/inject/dapi-envars-container.yaml" >}} +{{% codenew file="pods/inject/dapi-envars-container.yaml" %}} Dans ce fichier, vous pouvez voir 4 variables d'environnement. Le champ `env` est une liste de variables d'environnement. diff --git a/content/fr/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/fr/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 4d686301c9..77b3741eaf 100644 --- a/content/fr/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/fr/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -53,7 +53,9 @@ Pour apprendre comment déployer le Metrics Server, consultez la [documentation Pour démontrer un HorizontalPodAutoscaler, vous commencerez par démarrer un Deployment qui exécute un conteneur utilisant l'image `hpa-example` et l'expose en tant que {{< glossary_tooltip term_id="service">}} en utilisant le -manifeste suivant: {{< codenew file="application/php-apache.yaml" >}} +manifeste suivant: + +{{% codenew file="application/php-apache.yaml" %}} Pour créer les ressources, exécutez la commande suivante: ```shell @@ -505,7 +507,7 @@ Cela signifie que vous pouvez voir la valeur de votre métrique fluctuer entre ` Au lieu d'utiliser la commande `kubectl autoscale` pour créer un HorizontalPodAutoscaler de manière impérative, nous pouvons utiliser le manifeste suivant pour le créer de manière déclarative : -{{< codenew file=application/hpa/php-apache.yaml >}} +{{% codenew file=application/hpa/php-apache.yaml %}} Ensuite, créez l'autoscaler en exécutant la commande suivante : diff --git a/content/fr/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/fr/docs/tasks/run-application/run-single-instance-stateful-application.md index d9d99be845..5ee3ebbfe7 100644 --- a/content/fr/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/fr/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -37,8 +37,8 @@ Remarque: le mot de passe MySQL est défini dans le fichier de configuration YAM Voir les [secrets Kubernetes](/docs/concepts/configuration/secret/) pour une approche sécurisée. -{{< codenew file="application/mysql/mysql-deployment.yaml" >}} -{{< codenew file="application/mysql/mysql-pv.yaml" >}} +{{% codenew file="application/mysql/mysql-deployment.yaml" %}} +{{% codenew file="application/mysql/mysql-pv.yaml" %}} 1. Déployez le PV et le PVC du fichier YAML: diff --git a/content/fr/docs/tasks/run-application/run-stateless-application-deployment.md b/content/fr/docs/tasks/run-application/run-stateless-application-deployment.md index cb932a24cd..9e5d24ee47 100644 --- a/content/fr/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/fr/docs/tasks/run-application/run-stateless-application-deployment.md @@ -28,7 +28,7 @@ déploiement Kubernetes, et vous pouvez décrire un déploiement dans un fichier YAML. Par exemple, ce fichier YAML décrit un déploiement qui exécute l'image Docker nginx:1.14.2 : -{{< codenew file="application/deployment.yaml" >}} +{{% codenew file="application/deployment.yaml" %}} 1. Créez un déploiement basé sur ce fichier YAML: @@ -102,7 +102,7 @@ Vous pouvez mettre à jour le déploiement en appliquant un nouveau fichier YAML Ce fichier YAML indique que le déploiement doit être mis à jour pour utiliser nginx 1.16.1. -{{< codenew file="application/deployment-update.yaml" >}} +{{% codenew file="application/deployment-update.yaml" %}} 1. Appliquez le nouveau fichier YAML : @@ -121,7 +121,7 @@ pour utiliser nginx 1.16.1. Vous pouvez augmenter le nombre de pods dans votre déploiement en appliquant un nouveau fichier YAML. Ce fichier YAML définit `replicas` à 4, ce qui spécifie que le déploiement devrait avoir quatre pods : -{{< codenew file="application/deployment-scale.yaml" >}} +{{% codenew file="application/deployment-scale.yaml" %}} 1. Appliquez le nouveau fichier YAML : diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index f097b375a4..2c1b562405 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -39,9 +39,9 @@ Vous pouvez également suivre ce tutoriel si vous avez installé [Minikube local Ce tutoriel fournit une image de conteneur construite à partir des fichiers suivants : -{{< codenew language="js" file="minikube/server.js" >}} +{{% codenew language="js" file="minikube/server.js" %}} -{{< codenew language="conf" file="minikube/Dockerfile" >}} +{{% codenew language="conf" file="minikube/Dockerfile" %}} Pour plus d'informations sur la commande `docker build`, lisez la documentation de [Docker](https://docs.docker.com/engine/reference/commandline/build/). diff --git a/content/hi/docs/reference/glossary/job.md b/content/hi/docs/reference/glossary/job.md new file mode 100644 index 0000000000..a52140092d --- /dev/null +++ b/content/hi/docs/reference/glossary/job.md @@ -0,0 +1,19 @@ +--- +title: जॉब (Job) +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/job/ +short_description: > + एक परिमित या बैच कार्य जो पूरा होने तक चलता है। + +aka: +tags: +- fundamental +- core-object +- workload +--- + एक परिमित या बैच कार्य जो पूरा होने तक चलता है। + + + +जॉब एक या अधिक {{}} ऑब्जेक्ट बनाता है और सुनिश्चित करता है कि उनमें से एक निर्दिष्ट संख्या सफलतापूर्वक समाप्त हो जाए। जैसे ही पॉड्स सफलतापूर्वक पूर्ण होते हैं, जॉब उस सफल समापन को ट्रैक करता है। \ No newline at end of file diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md index 5fa480809c..30dfa12737 100644 --- a/content/id/docs/concepts/security/overview.md +++ b/content/id/docs/concepts/security/overview.md @@ -34,7 +34,7 @@ IaaS Provider | Link | Alibaba Cloud | https://www.alibabacloud.com/trust-center | Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | -Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html | +Huawei Cloud | https://www.huaweicloud.com/intl/id-id/securecenter/overallsafety | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | Oracle Cloud Infrastructure | https://www.oracle.com/security/ | diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index c05757cbba..f6053a131d 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -492,7 +492,7 @@ dan `scp` menggunakan pengguna lain tersebut. Berkas `admin.conf` memberikan penggunanya privilese (_privilege_) _superuser_ terhadap klaster. Berkas ini harus digunakan seperlunya. Untuk pengguna biasa, direkomendasikan untuk membuat kredensial unik dengan privilese _whitelist_. Kamu dapat melakukan -ini dengan perintah `kubeadm alpha kubeconfig user --client-name `. +ini dengan perintah `kubeadm kubeconfig user --client-name `. Perintah tersebut akan mencetak berkas KubeConfig ke STDOUT yang harus kamu simpan ke dalam sebuah berkas dan mendistribusikannya pada para pengguna. Setelah itu, whitelist privilese menggunakan `kubectl create (cluster)rolebinding`. diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md index a4e993d135..e0526360a8 100644 --- a/content/ja/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -210,7 +210,7 @@ kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m このセクションの残りの部分は、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバーがあることを前提にしています。ここではCoreDNSクラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/ja/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。 ```shell -kubectl run curl --image=radial/busyboxplus:curl -i --tty +kubectl run curl --image=radial/busyboxplus:curl -i --tty --rm ``` ``` Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index eba6d063d4..7076aa2063 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -52,7 +52,7 @@ Initコンテナを活用する方法について、いくつかのアイデア * シェルコマンドを使って単一の{{< glossary_tooltip text="Service" term_id="service">}}が作成されるのを待機する。 ```shell - for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 + for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1 ``` * 以下のようなコマンドを使って下位のAPIからPodの情報をリモートサーバに登録する。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 7f9ada0ecf..58494bb97c 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -132,7 +132,7 @@ kubeadmは`kubelet`や`kubectl`をインストールまたは管理**しない** 2. Google Cloudの公開鍵をダウンロードします: ```shell - curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg + curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg ``` 3. Kubernetesの`apt`リポジトリを追加します: diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 8e779564e3..a61f8a1892 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -147,7 +147,7 @@ Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実 ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 - .\PrepareNode.ps1 -KubernetesVersion {{% param "fullversion" %}} + .\PrepareNode.ps1 -KubernetesVersion v{{% skew currentPatchVersion %}} ``` 1. `kubeadm`を実行してノードに参加します diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 2cb8417976..3926038623 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -32,8 +32,8 @@ Windowsノードをアップグレードする前にコントロールプレー 1. Windowsノードから、kubeadmをアップグレードします。: ```powershell - # {{% param "fullversion" %}}を目的のバージョンに置き換えます - curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubeadm.exe + # {{% skew currentPatchVersion %}}を目的のバージョンに置き換えます + curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/v{{% skew currentPatchVersion %}}/bin/windows/amd64/kubeadm.exe ``` ### ノードをドレインする @@ -67,7 +67,7 @@ Windowsノードをアップグレードする前にコントロールプレー ```powershell stop-service kubelet - curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubelet.exe + curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/v{{% skew currentPatchVersion %}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` diff --git a/content/ja/docs/tutorials/services/connect-applications-service.md b/content/ja/docs/tutorials/services/connect-applications-service.md index 965645394d..90cad45a6d 100644 --- a/content/ja/docs/tutorials/services/connect-applications-service.md +++ b/content/ja/docs/tutorials/services/connect-applications-service.md @@ -134,7 +134,7 @@ my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s ## Serviceへのアクセス KubernetesはServiceを探す2つの主要なモードとして、環境変数とDNSをサポートしています。 -前者はすぐに動かせるのに対し、後者は[CoreDNSクラスターアドオン](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)が必要です。 +前者はすぐに動かせるのに対し、後者は[CoreDNSクラスターアドオン](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/coredns)が必要です。 {{< note >}} もしServiceの環境変数が望ましくないなら(想定しているプログラムの環境変数と競合する可能性がある、処理する変数が多すぎる、DNSだけ使いたい、など)、[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`のフラグを`false`にすることで、このモードを無効化できます。 diff --git a/content/ja/docs/tutorials/stateful-application/zookeeper.md b/content/ja/docs/tutorials/stateful-application/zookeeper.md new file mode 100644 index 0000000000..cddce817cd --- /dev/null +++ b/content/ja/docs/tutorials/stateful-application/zookeeper.md @@ -0,0 +1,1095 @@ +--- +title: 分散システムコーディネーターZooKeeperの実行 +content_type: tutorial +weight: 40 +--- + + +このチュートリアルでは、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、[PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)、[Podアンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を使って、Kubernetes上での[Apache Zookeeper](https://zookeeper.apache.org)の実行をデモンストレーションします。 + +## {{% heading "prerequisites" %}} + +このチュートリアルを始める前に、以下のKubernetesの概念について理解しておく必要があります。 + +- [Pod](/ja/docs/concepts/workloads/pods/) +- [クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/) +- [Headless Service](/ja/docs/concepts/services-networking/service/#headless-service) +- [PersistentVolume](/ja/docs/concepts/storage/volumes/) +- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) +- [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) +- [Podアンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +- [kubectl CLI](/docs/reference/kubectl/kubectl/) + +少なくとも4つのノードのクラスターが必要で、各ノードは少なくとも2つのCPUと4GiBのメモリが必須です。このチュートリアルでは、クラスターのノードをcordonおよびdrainします。 +**つまり、クラスターがそのノードの全てのPodを終了して退去させ、ノードが一時的にスケジュールできなくなる、ということです。** +このチュートリアル専用のクラスターを使うか、起こした破壊がほかのテナントに干渉しない確証を得ることをお勧めします。 + +このチュートリアルでは、クラスターがPersistentVolumeの動的なプロビジョニングが行われるように設定されていることを前提としています。 +クラスターがそのように設定されていない場合、チュートリアルを始める前に20GiBのボリュームを3つ、手動でプロビジョニングする必要があります。 + +## {{% heading "objectives" %}} + +このチュートリアルを終えると、以下の知識を得られます。 + +- StatefulSetを使ってZooKeeperアンサンブルをデプロイする方法。 +- アンサンブルを一貫して設定する方法。 +- ZooKeeperサーバーのデプロイをアンサンブルに広げる方法。 +- 計画されたメンテナンス中もサービスが利用可能であることを保証するためにPodDisruptionBudgetsを使う方法。 + + + +### ZooKeeper + +[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/)は、分散アプリケーションのための、分散型オープンソースコーディネーションサービスです。 +ZooKeeperでは、データの読み書き、および更新の監視ができます。 +データは階層化されてファイルシステム内に編成され、アンサンブル(ZooKeeperサーバーのセット)内の全てのZooKeeperサーバーに複製されます。 +データへの全ての操作はアトミックかつ逐次的に一貫性を持ちます。 +ZooKeeperは、アンサンブル内の全てのサーバー間でステートマシンを複製するために[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf)合意プロトコルを使ってこれを保証します。 + +アンサンブルはリーダーを選出するのにZabプロトコルを使い、選出が完了するまでデータを書き出しません。 +完了すると、アンサンブルは複製するのにZabを使い、書き込みが承認されてクライアントに可視化されるより前に、全ての書き込みをクォーラムに複製することを保証します。 +重み付けされたクォーラムでなければ、クォーラムは現在のリーダーを含むアンサンブルの過半数を占めるコンポーネントです。 +例えばアンサンブルが3つのサーバーを持つ時、リーダーとそれ以外のもう1つのサーバーを含むコンポーネントが、クォーラムを構成します。 +アンサンブルがクォーラムに達しない場合、アンサンブルはデータを書き出せません。 + +ZooKeeperサーバー群はそれらの全てのステートマシンをメモリに保持し、それぞれの変化をストレージメディア上の永続的なWAL(Write Ahead Log)に書き出します。 +サーバーがクラッシュした時には、WALをリプレーすることで以前のステートに回復できます。 +WALを際限のない増加から防ぐために、ZooKeeperサーバーは、メモリステートにあるものをストレージメディアに定期的にスナップショットします。 +これらのスナップショットはメモリに直接読み込むことができ、スナップショットより前の全てのWALエントリは破棄され得ます。 + +## ZooKeeperアンサンブルの作成 + +以下のマニフェストは[Headless Service](/ja/docs/concepts/services-networking/service/#headless-services)、[Service](/ja/docs/concepts/services-networking/service/)、[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets)、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を含んでいます。 + +{{< codenew file="application/zookeeper/zookeeper.yaml" >}} + +ターミナルを開き、マニフェストを作成するために +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)コマンドを使います。 + +```shell +kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml +``` + +これは`zk-hs` Headless Service、`zk-cs` Service、`zk-pdb` PodDisruptionBudget、 `zk` StatefulSetを作成します。 + +``` +service/zk-hs created +service/zk-cs created +poddisruptionbudget.policy/zk-pdb created +statefulset.apps/zk created +``` + +StatefulSetのPodを作成するStatefulSetコントローラーを監視するため、[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使います。 + +```shell +kubectl get pods -w -l app=zk +``` + +`zk-2` PodがRunningおよびReadyになったら、`CTRL-C`でkubectlを終了してください。 + +``` +NAME READY STATUS RESTARTS AGE +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 19s +zk-0 1/1 Running 0 40s +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 0s +zk-1 0/1 ContainerCreating 0 0s +zk-1 0/1 Running 0 18s +zk-1 1/1 Running 0 40s +zk-2 0/1 Pending 0 0s +zk-2 0/1 Pending 0 0s +zk-2 0/1 ContainerCreating 0 0s +zk-2 0/1 Running 0 19s +zk-2 1/1 Running 0 40s +``` + +StatefulSetコントローラーが3つのPodを作成し、各Podは[ZooKeeper](https://archive.apache.org/dist/zookeeper/stable/)サーバー付きのコンテナを持ちます。 + +### リーダーの選出のファシリテート {#facilitating-leader-election} + +匿名のネットワークにおいてリーダー選出を終了するアルゴリズムがないので、Zabはリーダー選出のための明示的なメンバーシップ設定を要します。 +アンサンブルの各サーバーはユニーク識別子を持つ必要があり、全てのサーバーは識別子のグローバルセットを知っている必要があり、各識別子はネットワークアドレスと関連付けられている必要があります。 + +`zk` StatefulSetのPodのホスト名を取得するために[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)を使います。 + +```shell +for i in 0 1 2; do kubectl exec zk-$i -- hostname; done +``` + +StatefulSetコントローラーは各Podに、その順序インデックスに基づくユニークなホスト名を提供します。 +ホスト名は`-<順序インデックス>`という形をとります。 +`zk` StatefulSetの`replicas`フィールドが`3`にセットされているので、このセットのコントローラーは、ホスト名にそれぞれ`zk-0`、`zk-1`、`zk-2`が付いた3つのPodを作成します。 + +``` +zk-0 +zk-1 +zk-2 +``` + +ZooKeeperアンサンブルのサーバーは、ユニーク識別子として自然数を使い、それぞれのサーバーの識別子をサーバーのデータディレクトリ内の`myid`というファイルに格納します。 + +各サーバーの`myid`ファイルの内容を調べるには、以下のコマンドを使います。 + +```shell +for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done +``` + +識別子が自然数で順序インデックスは正の整数なので、順序に1を加算することで識別子を生成できます。 + +``` +myid zk-0 +1 +myid zk-1 +2 +myid zk-2 +3 +``` + +`zk` StatefulSet内の各Podの完全修飾ドメイン名(FQDN)を取得するには、以下のコマンドを使います。 + +```shell +for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done +``` + +`zk-hs` Serviceは、全Podのためのドメイン`zk-hs.default.svc.cluster.local`を作成します。 + +``` +zk-0.zk-hs.default.svc.cluster.local +zk-1.zk-hs.default.svc.cluster.local +zk-2.zk-hs.default.svc.cluster.local +``` + +[Kubernetes DNS](/ja/docs/concepts/services-networking/dns-pod-service/)のAレコードは、FQDNをPodのIPアドレスに解決します。 +KubernetesがPodを再スケジュールした場合、AレコードはPodの新しいIPアドレスに更新されますが、Aレコードの名前は変更されません。 + +ZooKeeperはそのアプリケーション設定を`zoo.cfg`という名前のファイルに格納します。 +`zk-0` Pod内の`zoo.cfg`ファイルの内容を見るには、`kubectl exec`を使います。 + +```shell +kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg +``` + +ファイル末尾にある`server.1`、`server.2`、`server.3`のプロパティの、`1`、`2`、`3`はZooKeeperサーバーの`myid`ファイル内の識別子に対応します。 +これらは`zk` StatefulSet内のPodのFQDNにセットされます。 + +``` +clientPort=2181 +dataDir=/var/lib/zookeeper/data +dataLogDir=/var/lib/zookeeper/log +tickTime=2000 +initLimit=10 +syncLimit=2000 +maxClientCnxns=60 +minSessionTimeout= 4000 +maxSessionTimeout= 40000 +autopurge.snapRetainCount=3 +autopurge.purgeInterval=0 +server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 +server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 +server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 +``` + +### 合意形成 {#achieving-consensus} + +合意(consensus)プロトコルは、各参加者の識別子がユニークであることを要件としています。 +Zabプロトコル内で同じユニーク識別子を主張する2つの参加者はないものとします。 +これは、システム内のプロセスが、どのプロセスがどのデータをコミットしたかを同意できるようにするために必須です。 +2つのPodが同じ順序値で起動されたなら、2つのZooKeeperサーバーはどちらもそれら自身を同じサーバーとして認識してしまうでしょう。 + +```shell +kubectl get pods -w -l app=zk +``` + +``` +NAME READY STATUS RESTARTS AGE +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 19s +zk-0 1/1 Running 0 40s +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 0s +zk-1 0/1 ContainerCreating 0 0s +zk-1 0/1 Running 0 18s +zk-1 1/1 Running 0 40s +zk-2 0/1 Pending 0 0s +zk-2 0/1 Pending 0 0s +zk-2 0/1 ContainerCreating 0 0s +zk-2 0/1 Running 0 19s +zk-2 1/1 Running 0 40s +``` + +各PodのAレコードは、PodがReadyになった時に記入されます。そのため、ZooKeeperサーバー群のFQDNはある1つのエンドポイント、すなわち`myid`ファイルで設定された識別子を主張するユニークなZooKeeperサーバーに解決されます。 + +``` +zk-0.zk-hs.default.svc.cluster.local +zk-1.zk-hs.default.svc.cluster.local +zk-2.zk-hs.default.svc.cluster.local +``` + +これは、ZooKeeperの`zoo.cfg`ファイル内の`servers`プロパティが正しく設定されたアンサンブルを表していることを保証します。 + +``` +server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 +server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 +server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 +``` + +サーバーが値のコミットを試みるためにZabプロトコルを使う時、(リーダー選出が成功していて、少なくともPodのうちの2つがRunningおよびReadyならば)それぞれのサーバーは双方の合意をとって値をコミット、あるいは、(もし双方の状態が合わなければ)それを行うことに失敗します。 +あるサーバーが別のサーバーを代行して書き込みを承認する状態は発生しません。 + +### アンサンブルの健全性テスト {#sanity-testing-the-ensemble} + +最も基本的な健全性テストは、データを1つのZooKeeperサーバーに書き込み、そのデータを別のサーバーで読み取ることです。 + +以下のコマンドは、`world`をアンサンブル内の`zk-0` Podのパス`/hello`に書き込むのに、`zkCli.sh`スクリプトを実行します。 + +```shell +kubectl exec zk-0 -- zkCli.sh create /hello world +``` + +``` +WATCHER:: + +WatchedEvent state:SyncConnected type:None path:null +Created /hello +``` + +`zk-1` Podからデータを取得するには、以下のコマンドを使います。 + +```shell +kubectl exec zk-1 -- zkCli.sh get /hello +``` + +`zk-0`に作成したデータは、アンサンブル内の全てのサーバーで利用できます。 + +``` +WATCHER:: + +WatchedEvent state:SyncConnected type:None path:null +world +cZxid = 0x100000002 +ctime = Thu Dec 08 15:13:30 UTC 2016 +mZxid = 0x100000002 +mtime = Thu Dec 08 15:13:30 UTC 2016 +pZxid = 0x100000002 +cversion = 0 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 5 +numChildren = 0 +``` + +### 永続的なストレージの提供 + +[ZooKeeperの概要](#zookeeper)のセクションで言及したように、 +ZooKeeperは全てのエントリを永続的なWALにコミットし、定期的にメモリ状態のスナップショットをストレージメディアに書き出します。 +永続性を提供するためにWALを使用するのは、複製されたステートマシンを立てるために合意プロトコルを使うアプリケーションでよくあるテクニックです。 + +`zk` StatefulSetを削除するために、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)コマンドを使います。 + +```shell +kubectl delete statefulset zk +``` + +``` +statefulset.apps "zk" deleted +``` + +StatefulSet内のPodの終了を観察します。 + +```shell +kubectl get pods -w -l app=zk +``` + +`zk-0`が完全に終了したら、`CTRL-C`でkubectlを終了します。 + +``` +zk-2 1/1 Terminating 0 9m +zk-0 1/1 Terminating 0 11m +zk-1 1/1 Terminating 0 10m +zk-2 0/1 Terminating 0 9m +zk-2 0/1 Terminating 0 9m +zk-2 0/1 Terminating 0 9m +zk-1 0/1 Terminating 0 10m +zk-1 0/1 Terminating 0 10m +zk-1 0/1 Terminating 0 10m +zk-0 0/1 Terminating 0 11m +zk-0 0/1 Terminating 0 11m +zk-0 0/1 Terminating 0 11m +``` + +`zookeeper.yaml`のマニフェストを再適用します。 + +```shell +kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml +``` + +これは`zk` StatefulSetオブジェクトを作成しますが、マニフェストのその他のAPIオブジェクトはすでに存在しているので変更されません。 + +StatefulSetコントローラーがStatefulSetのPodを再作成するのを見てみます。 + +```shell +kubectl get pods -w -l app=zk +``` + +`zk-2` PodがRunningおよびReadyになったら、`CTRL-C`でkubectlを終了します。 + +``` +NAME READY STATUS RESTARTS AGE +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 19s +zk-0 1/1 Running 0 40s +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 0s +zk-1 0/1 ContainerCreating 0 0s +zk-1 0/1 Running 0 18s +zk-1 1/1 Running 0 40s +zk-2 0/1 Pending 0 0s +zk-2 0/1 Pending 0 0s +zk-2 0/1 ContainerCreating 0 0s +zk-2 0/1 Running 0 19s +zk-2 1/1 Running 0 40s +``` + +[健全性テスト](#sanity-testing-the-ensemble)で入力した値を`zk-2` Podから取得するには、以下のコマンドを使います。 + +```shell +kubectl exec zk-2 zkCli.sh get /hello +``` + +`zk` StatefulSet内の全てのPodを終了して再作成したにもかかわらず、アンサンブルは元の値をなおも供給します。 + +``` +WATCHER:: + +WatchedEvent state:SyncConnected type:None path:null +world +cZxid = 0x100000002 +ctime = Thu Dec 08 15:13:30 UTC 2016 +mZxid = 0x100000002 +mtime = Thu Dec 08 15:13:30 UTC 2016 +pZxid = 0x100000002 +cversion = 0 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 5 +numChildren = 0 +``` + +`zk` StatefulSetの`spec`の`volumeClaimTemplates`フィールドは、各PodにプロビジョニングされるPersistentVolumeを指定します。 + +```yaml +volumeClaimTemplates: + - metadata: + name: datadir + annotations: + volume.alpha.kubernetes.io/storage-class: anything + spec: + accessModes: [ "ReadWriteOnce" ] + resources: + requests: + storage: 20Gi +``` + +`StatefulSet`コントローラーは、`StatefulSet`内の各Podのために`PersistentVolumeClaim`を生成します。 + +`StatefulSet`の`PersistentVolumeClaims`を取得するために、以下のコマンドを使います。 + +```shell +kubectl get pvc -l app=zk +``` + +`StatefulSet`がそのPodを再作成した時、`StatefulSet`はPodのPersistentVolumeを再マウントします。 + +``` +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h +datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h +datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi RWO 1h +``` + +`StatefulSet`のコンテナ`template`の`volumeMounts`セクションは、ZooKeeperサーバーのデータディレクトリにあるPersistentVolumeをマウントします。 + +```yaml +volumeMounts: +- name: datadir + mountPath: /var/lib/zookeeper +``` + +`zk` `StatefulSet`内のPodが(再)スケジュールされると、ZooKeeperサーバーのデータディレクトリにマウントされた同じ`PersistentVolume`を常に得ます。 +Podが再スケジュールされたとしても、全ての書き込みはZooKeeperサーバーのWALおよび全スナップショットに行われ、永続性は残ります。 + +## 一貫性のある設定の保証 + +[リーダーの選出のファシリテート](#facilitating-leader-election)および[合意形成](#achieving-consensus)のセクションで記したように、ZooKeeperのアンサンブル内のサーバー群は、リーダーを選出しクォーラムを形成するための一貫性のある設定を必要とします。 +また、プロトコルがネットワーク越しで正しく動作するために、Zabプロトコルの一貫性のある設定も必要です。 +この例では、設定を直接マニフェストに埋め込むことで一貫性のある設定を達成します。 + +`zk` StatefulSetを取得しましょう。 + +```shell +kubectl get sts zk -o yaml +``` + +``` +… +command: + - sh + - -c + - "start-zookeeper \ + --servers=3 \ + --data_dir=/var/lib/zookeeper/data \ + --data_log_dir=/var/lib/zookeeper/data/log \ + --conf_dir=/opt/zookeeper/conf \ + --client_port=2181 \ + --election_port=3888 \ + --server_port=2888 \ + --tick_time=2000 \ + --init_limit=10 \ + --sync_limit=5 \ + --heap=512M \ + --max_client_cnxns=60 \ + --snap_retain_count=3 \ + --purge_interval=12 \ + --max_session_timeout=40000 \ + --min_session_timeout=4000 \ + --log_level=INFO" +… +``` + +このcommandでは、ZooKeeperサーバーを開始するためにコマンドラインパラメータで設定を渡しています。 +設定をアンサンブルへ渡すのには環境変数を使うこともできます。 + +### ログの設定 + +`zkGenConfig.sh`スクリプトで生成されたファイルの1つは、ZooKeeperのログを制御します。 +ZooKeeperは[Log4j](https://logging.apache.org/log4j/2.x/)を使い、デフォルトではログの設定に基づいて、ログ設定に時間およびサイズベースでのローリングファイルアペンダー(ログのローテーション)を使用します。 + +`zk` `StatefulSet`内のPodの1つからログ設定を取得するには、以下のコマンドを使います。 + +```shell +kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties +``` + +以下のログ設定は、ZooKeeperにログの全てを標準出力ファイルストリームに書き出す処理をさせます。 + +``` +zookeeper.root.logger=CONSOLE +zookeeper.console.threshold=INFO +log4j.rootLogger=${zookeeper.root.logger} +log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender +log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold} +log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout +log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n +``` + +これはログコンテナ内のログを安全にとるための、最もシンプルと思われる方法です。 +アプリケーションはログを標準出力に書き出し、Kubernetesがログのローテーションを処理してくれます。 +Kubernetesは、標準出力と標準エラー出力に書き出されるアプリケーションのログがローカルストレージメディアを使い尽くさないことを保証する、健全維持ポリシーも実装しています。 + +Podの1つから末尾20行を取得するために、[`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs)を使ってみます。 + +```shell +kubectl logs zk-0 --tail 20 +``` + +`kubectl logs`を利用するか、Kubernetes Dashboardから、標準出力または標準エラーに書き出されたアプリケーションログを参照できます。 + +``` +2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740 +2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client) +2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749 +2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52749 +2016-12-06 19:34:26,156 [myid:1] - INFO [Thread-1137:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52749 (no session established for client) +2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52750 +2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52750 +2016-12-06 19:34:26,226 [myid:1] - INFO [Thread-1138:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52750 (no session established for client) +2016-12-06 19:34:36,151 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52760 +2016-12-06 19:34:36,152 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52760 +2016-12-06 19:34:36,152 [myid:1] - INFO [Thread-1139:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52760 (no session established for client) +2016-12-06 19:34:36,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52761 +2016-12-06 19:34:36,231 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52761 +2016-12-06 19:34:36,231 [myid:1] - INFO [Thread-1140:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52761 (no session established for client) +2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52767 +2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52767 +2016-12-06 19:34:46,149 [myid:1] - INFO [Thread-1141:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52767 (no session established for client) +2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52768 +2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52768 +2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) +``` + +Kubernetesは多くのログソリューションを統合しています。 +クラスターおよびアプリケーションに最も適合するログソリューションを選べます。 +クラスターレベルのロギングとアグリゲーションとして、ログをローテートおよび輸送するための[サイドカーコンテナ](/ja/docs/concepts/cluster-administration/logging#sidecar-container-with-logging-agent)をデプロイすることを検討してください。 + +### 非特権ユーザーの設定 + +コンテナ内で特権ユーザーとしての実行をアプリケーションに許可するベストプラクティスは、議論の的です。 +アプリケーションが非特権ユーザーとして動作することを組織で必須としているなら、エントリポイントがそのユーザーとして実行できるユーザーを制御する[セキュリティコンテキスト](/ja/docs/tasks/configure-pod-container/security-context/)を利用できます。 + +`zk` `StatefulSet`のPod `template`は、`SecurityContext`を含んでいます。 + +```yaml +securityContext: + runAsUser: 1000 + fsGroup: 1000 +``` + +Podのコンテナ内で、UID 1000はzookeeperユーザーに、GID 1000はzookeeperグループにそれぞれ相当します。 + +`zk-0` PodからのZooKeeperプロセス情報を取得してみましょう。 + +```shell +kubectl exec zk-0 -- ps -elf +``` + +`securityContext`オブジェクトの`runAsUser`フィールドが1000にセットされているとおり、ZooKeeperプロセスは、rootとして実行される代わりにzookeeperユーザーとして実行されています。 + +``` +F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD +4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground +0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg +``` + +デフォルトでは、PodのPersistentVolumeがZooKeeperサーバーのデータディレクトリにマウントされている時、rootユーザーのみがそこにアクセス可能です。 +この設定はZooKeeperのプロセスがそのWALに書き込んだりスナップショットに格納したりするのを妨げることになります。 + +`zk-0` PodのZooKeeperデータディレクトリのファイルパーミッションを取得するには、以下のコマンドを使います。 + +```shell +kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data +``` + +`securityContext`オブジェクトの`fsGroup`フィールドが1000にセットされているので、PodのPersistentVolumeの所有権はzookeeperグループにセットされ、ZooKeeperのプロセスがそのデータを読み書きできるようになります。 + +``` +drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data +``` + +## ZooKeeperプロセスの管理 + +[ZooKeeperドキュメント](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision)では、「You will want to have a supervisory process that manages each of your ZooKeeper server processes (JVM).(各ZooKeeperサーバープロセス(JVM)を管理する監督プロセスを持ちたくなります)」と述べています。 +分散型システム内で失敗したプロセスを再起動するのにwatchdog(監督プロセス)を使うのは、典型的パターンです。 +アプリケーションをKubernetesにデプロイする時には、監督プロセスのような外部ユーティリティを使うよりもむしろ、アプリケーションのwatchdogとしてKubernetesを使うべきです。 + +### アンサンブルのアップデート + +`zk` `StatefulSet`は`RollingUpdate`アップデート戦略を使うように設定されています。 +サーバーに割り当てられる`cpus`の数を更新するのに、`kubectl patch`を利用できます。 + + +```shell +kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' +``` + +``` +statefulset.apps/zk patched +``` + +更新の状況を見るには、`kubectl rollout status`を使います。 + +```shell +kubectl rollout status sts/zk +``` + +``` +waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664... +Waiting for 1 pods to be ready... +Waiting for 1 pods to be ready... +statefulset rolling update complete 3 pods at revision zk-5db4499664... +``` + +これはPod群を終了し、逆の順番で1つずつそれらを新しい設定で再作成します。 +これはクォーラムがローリングアップデート中に維持されることを保証します。 + +履歴や過去の設定を見るには、`kubectl rollout history`コマンドを使います。 + +```shell +kubectl rollout history sts/zk +``` + +出力は次のようになります: + +``` +statefulsets "zk" +REVISION +1 +2 +``` + +変更をロールバックするには、`kubectl rollout undo`コマンドを使います。 + +```shell +kubectl rollout undo sts/zk +``` + +出力は次のようになります: + +``` +statefulset.apps/zk rolled back +``` + +### プロセスの失敗の取り扱い + +[再起動ポリシー](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は、Pod内のコンテナのエントリポイントへのプロセスの失敗をKubernetesがどのように取り扱うかを制御します。 +`StatefulSet`内のPodにおいて唯一妥当な`RestartPolicy`はAlwaysで、これはデフォルト値です。 +ステートフルなアプリケーションでは、このデフォルトポリシーの上書きは**絶対にすべきではありません**。 + +`zk-0` Pod内で実行されているZooKeeperサーバーのプロセスツリーを調査するには、以下のコマンドを使います。 + +```shell +kubectl exec zk-0 -- ps -ef +``` + +コンテナのエントリポイントとして使われるコマンドはPID 1、エントリポイントの子であるZooKeeperプロセスはPID 27となっています。 + +``` +UID PID PPID C STIME TTY TIME CMD +zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground +zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg +``` + +別のターミナルで、以下のコマンドを使って`zk` `StatefulSet`内のPodを見てみます。 + +```shell +kubectl get pod -w -l app=zk +``` + + +別のターミナルで、以下のコマンドを使ってPod `zk-0`内のZooKeeperプロセスを終了します。 + +```shell +kubectl exec zk-0 -- pkill java +``` + +ZooKeeperプロセスの終了は、その親プロセスの終了を引き起こします。 +コンテナの`RestartPolicy`はAlwaysなので、親プロセスが再起動(restart)されます。 + +``` +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Running 0 21m +zk-1 1/1 Running 0 20m +zk-2 1/1 Running 0 19m +NAME READY STATUS RESTARTS AGE +zk-0 0/1 Error 0 29m +zk-0 0/1 Running 1 29m +zk-0 1/1 Running 1 29m +``` + +アプリケーションが、そのビジネスロジックを実装するプロセスを立ち上げるのにスクリプト(`zkServer.sh`など)を使っている場合、スクリプトは子プロセスとともに終了する必要があります。 +これは、Kubernetesがアプリケーションのコンテナを、そのビジネスロジックを実装しているプロセスが失敗した時に再起動することを保証します。 + +### 生存性(liveness)テスト + +失敗したプロセスを再起動するための設定をアプリケーションに施すのは、分散型システムの健全さを保つのに十分ではありません。 +システムのプロセスが生きていることもあれば無反応なこともあり、あるいはそうでなく不健全という状況もあります。 +アプリケーションのプロセスが不健全で再起動すべきであることをKubernetesに通知するには、liveness probeを使うのがよいでしょう。 + +`zk` `StatefulSet`のPod `template`でliveness probeを指定します。 + +```yaml + livenessProbe: + exec: + command: + - sh + - -c + - "zookeeper-ready 2181" + initialDelaySeconds: 15 + timeoutSeconds: 5 +``` + +プローブはサーバーの健全さをテストするのに、ZooKeeperの`ruok` 4文字コマンドを使うbashスクリプトを呼び出します。 + +``` +OK=$(echo ruok | nc 127.0.0.1 $1) +if [ "$OK" == "imok" ]; then + exit 0 +else + exit 1 +fi +``` + +ターミナルウィンドウで、`zk` StatefulSet内のPodを見るのに以下のコマンドを使います。 + +```shell +kubectl get pod -w -l app=zk +``` + +別のウィンドウで、Pod `zk-0`のファイルシステムから`zookeeper-ready`スクリプトを削除するために以下のコマンドを使います。 + +```shell +kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready +``` + +ZooKeeperプロセスの失敗のためにliveness probeを使う時、アンサンブル内の不健全なプロセスが再起動されることを保証するために、Kubernetesは自動的にプロセスを再起動します。 + +```shell +kubectl get pod -w -l app=zk +``` + +``` +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Running 0 1h +zk-1 1/1 Running 0 1h +zk-2 1/1 Running 0 1h +NAME READY STATUS RESTARTS AGE +zk-0 0/1 Running 0 1h +zk-0 0/1 Running 1 1h +zk-0 1/1 Running 1 1h +``` + +### 準備性(readiness)テスト + +準備性は生存性と同じではありません。 +プロセスが生きているのであれば、スケジュールされ健全です。 +プロセスの準備ができたら、入力を処理できます。 +生存性はなくてはならないものですが、準備性の状態には十分ではありません。 +プロセスは生きてはいるが準備はできていない時、特に初期化および終了の間がそのケースに相当します。 + +readiness probeを指定するとKubernetesは、準備性チェックに合格するまで、アプリケーションのプロセスがネットワークトラフィックを受け取らないことを保証します。 + +ZooKeeperサーバーにとって、健全性は準備性を意味します。 +そのため、`zookeeper.yaml`マニフェストからのreadiness probeは、liveness probeと同一です。 + +```yaml + readinessProbe: + exec: + command: + - sh + - -c + - "zookeeper-ready 2181" + initialDelaySeconds: 15 + timeoutSeconds: 5 +``` + +liveness probeとreadiness probeが同一だとしても、両方を指定することが重要です。 +これは、ZooKeeperアンサンブル内の健全なサーバーだけがネットワークトラフィックを受け取ることを保証します。 + +## ノードの失敗の許容 + +ZooKeeperはデータの変更を正しくコミットするのにサーバーのクォーラムを必要とします。 +3つのサーバーのアンサンブルにおいては、書き込みの成功のために2つのサーバーは健全でなければなりません。 +クォーラムベースのシステムにおいて、可用性を保証するために、メンバーは障害ドメインにデプロイされます。 +個々のマシンの損失による障害を避けるためのベストプラクティスは、同じマシン上でアプリケーションの複数のインスタンスがコロケート(同じ場所に配置)されないようにすることです。 + +デフォルトでKubernetesは、同じノードの`StatefulSet`にPodをコロケートします。 +3つのサーバーアンサンブルを作成していたとして、2つのサーバーが同じノードにあり、そのノードが障害を起こした場合、ZooKeeperサービスのクライアントは、少なくともPodの1つが再スケジュールされるまで障害に見舞われることになります。 + +クリティカルシステムのプロセスがノードの失敗イベントで再スケジュールできるよう、追加のキャパシティを常にプロビジョンしておくべきです。 +そうしておけば、障害は単にKubernetesのスケジューラーがZooKeeperのサーバーの1つを再スケジュールするまでの辛抱です。 +ただし、ダウンタイムなしでノードの障害への耐性をサービスに持たせたいなら、`podAntiAffinity`をセットすべきです。 + +`zk` `StatefulSet`内のPodのノードを取得するには、以下のコマンドを使います。 + +```shell +for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done +``` + +`zk` `StatefulSet`内の全てのPodは、別々のノードにデプロイされます。 + +``` +kubernetes-node-cxpk +kubernetes-node-a5aq +kubernetes-node-2g2d +``` + +これは`zk` `StatefulSet`内のPodに`PodAntiAffinity`の指定があるからです。 + +```yaml +affinity: + podAntiAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + - labelSelector: + matchExpressions: + - key: "app" + operator: In + values: + - zk + topologyKey: "kubernetes.io/hostname" +``` + +`requiredDuringSchedulingIgnoredDuringExecution`フィールドは、`topologyKey`で定義されたドメイン内で`app`ラベルの値が`zk`の2つのPodが絶対にコロケートすべきでないことを、Kubernetes Schedulerに指示します。 +`topologyKey`の`kubernetes.io/hostname`は、ドメインが固有ノードであることを示しています。 +異なるルール、ラベル、セレクターを使って、物理・ネットワーク・電源といった障害ドメイン全体に広がるアンサンブルにこのテクニックを広げることができます。 + +## メンテナンス時の存続 + +このセクションでは、ノードをcordon(スケジュール不可化)およびdorain(解放)します。もし共有クラスターでこのチュートリアルを試しているのであれば、これがほかのテナントに有害な影響を及ぼさないことを確認してください。 + +前のセクションでは、計画外のノード障害に備えてどのようにPodをノード全体に広げるかを示しましたが、計画されたメンテナンスのため引き起こされる一時的なノード障害に対して計画する必要もあります。 + +クラスター内のノードを取得するために、以下のコマンドを使います。 + +```shell +kubectl get nodes +``` + +このチュートリアルでは、4つのノードのあるクラスターを仮定しています。 +クラスターが4つよりも多くある場合には、4つのノード以外全てをcordonするために[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)を使ってください。 +ノードを4つに制約することで、以下のメンテナンスシミュレーションにおいてzookeeper Podをスケジュールした時に、KubernetesがアフィニティとPodDisruptionBudget制約に遭遇することを保証します。 + +```shell +kubectl cordon <ノード名> +``` + +`zk-pdb`の`PodDisruptionBudget`を取得するために、以下のコマンドを使います。 + +```shell +kubectl get pdb zk-pdb +``` + +`max-unavailable`フィールドは、`zk` `StatefulSet`の最大で1つのPodがいつでも利用できなくなる可能性があるということを、Kubernetesに指示します。 + +``` +NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE +zk-pdb N/A 1 1 +``` + +1つ目のターミナルで、`zk` `StatefulSet`内のPodを見るのに以下のコマンドを使います。 + +```shell +kubectl get pods -w -l app=zk +``` + +次に別のターミナルで、Podが現在スケジュールされているノードを取得するために、以下のコマンドを使います。 + +```shell +for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done +``` + +出力は次のようになります: + +``` +kubernetes-node-pb41 +kubernetes-node-ixsl +kubernetes-node-i4c4 +``` + +`zk-0` Podがスケジュールされているノードをcordonおよびdrainするには、[`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)を使います。 + + +```shell +kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data +``` + +出力は次のようになります: + +``` +node "kubernetes-node-pb41" cordoned + +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz +pod "zk-0" deleted +node "kubernetes-node-pb41" drained +``` + +クラスターに4つのノードがあるので、`kubectl drain`は成功し、`zk-0`が別のノードに再スケジュールされます。 + +``` +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Running 2 1h +zk-1 1/1 Running 0 1h +zk-2 1/1 Running 0 1h +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 51s +zk-0 1/1 Running 0 1m +``` + +最初のターミナルで`StatefulSet`のPodを見守り、`zk-1`がスケジュールされたノードをdrainします。 + +```shell +kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data +``` + +出力は次のようになります: + +``` +"kubernetes-node-ixsl" cordoned +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74 +pod "zk-1" deleted +node "kubernetes-node-ixsl" drained +``` + +`zk` `StatefulSet`がPodのコロケーションを抑止する`PodAntiAffinity`ルールを含んでいるので、`zk-1` Podはスケジュールされず、またスケジュール可能なのは2つのノードだけなので、PodはPendingの状態のままになっています。 + +```shell +kubectl get pods -w -l app=zk +``` + +出力は次のようになります: + +``` +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Running 2 1h +zk-1 1/1 Running 0 1h +zk-2 1/1 Running 0 1h +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 51s +zk-0 1/1 Running 0 1m +zk-1 1/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 0s +``` + +StatefulSetのPodを見続け、`zk-2`がスケジュールされているノードをdrainします。 + +```shell +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data +``` + +出力は次のようになります: + +``` +node "kubernetes-node-i4c4" cordoned + +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog +WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4 +There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget. +pod/zk-2 +``` + +kubectlを終了するために`CTRL-C`を押します。 + +`zk-2`を退去させると`zk-budget`違反になってしまうので、3つ目のノードはdrainできません。ただし、ノードはcordonされたままとなります。 + +健全性テスト中に入力した値を`zk-0`から取得するには、`zkCli.sh`を使います。 + +```shell +kubectl exec zk-0 zkCli.sh get /hello +``` + +`PodDisruptionBudget`が遵守されているので、サービスはまだ利用可能です。 + +``` +WatchedEvent state:SyncConnected type:None path:null +world +cZxid = 0x200000002 +ctime = Wed Dec 07 00:08:59 UTC 2016 +mZxid = 0x200000002 +mtime = Wed Dec 07 00:08:59 UTC 2016 +pZxid = 0x200000002 +cversion = 0 +dataVersion = 0 +aclVersion = 0 +ephemeralOwner = 0x0 +dataLength = 5 +numChildren = 0 +``` + +最初のノードをuncordon(スケジュール可能化)するには、[`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon)を使います。 + +```shell +kubectl uncordon kubernetes-node-pb41 +``` + +出力は次のようになります: + +``` +node "kubernetes-node-pb41" uncordoned +``` + +`zk-1`はこのノードで再スケジュールされます。`zk-1`がRunningおよびReadyになるまで待ちます。 + +```shell +kubectl get pods -w -l app=zk +``` + +出力は次のようになります: + +``` +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Running 2 1h +zk-1 1/1 Running 0 1h +zk-2 1/1 Running 0 1h +NAME READY STATUS RESTARTS AGE +zk-0 1/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Terminating 2 2h +zk-0 0/1 Pending 0 0s +zk-0 0/1 Pending 0 0s +zk-0 0/1 ContainerCreating 0 0s +zk-0 0/1 Running 0 51s +zk-0 1/1 Running 0 1m +zk-1 1/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Terminating 0 2h +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 0s +zk-1 0/1 Pending 0 12m +zk-1 0/1 ContainerCreating 0 12m +zk-1 0/1 Running 0 13m +zk-1 1/1 Running 0 13m +``` + +試しに`zk-2`がスケジュールされているノードをdrainしてみます。 + +```shell +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data +``` + +出力は次のようになります: + +``` +node "kubernetes-node-i4c4" already cordoned +WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog +pod "heapster-v1.2.0-2604621511-wht1r" deleted +pod "zk-2" deleted +node "kubernetes-node-i4c4" drained +``` + +今度は`kubectl drain`は成功しました。 + +`zk-2`の再スケジュールができるように、2つ目のノードをuncordonします。 + +```shell +kubectl uncordon kubernetes-node-ixsl +``` + +出力は次のようになります: + +``` +node "kubernetes-node-ixsl" uncordoned +``` + +サービスがメンテナンス中も利用可能なままであることを保証するために、`PodDisruptionBudgets`とあわせて`kubectl drain`を利用できます。 +メンテナンスでノードがオフラインになる前にノードをcordonして、Podを退去させるのにdrainが使われている場合、Disruption Budget(停止状態の予算)を表すサービスは遵守すべきバジェットを持ちます。 +クリティカルサービスでは、Podをすぐに再スケジュールできるよう、追加のキャパティを常に割り当てておくべきです。 + +## {{% heading "cleanup" %}} + +- クラスターの全てのノードをuncordonするために、`kubectl uncordon`を実行してください。 +- このチュートリアルで使ったPersistentVolumeの永続的なストレージメディアを削除する必要があります。 + 全てのストレージが回収されたことを確実とするために、お使いの環境、ストレージ設定、プロビジョニング方法に基いて必要な手順に従ってください。 diff --git a/content/pt-br/docs/concepts/security/overview.md b/content/pt-br/docs/concepts/security/overview.md index 6203d6f949..12844b5dc3 100644 --- a/content/pt-br/docs/concepts/security/overview.md +++ b/content/pt-br/docs/concepts/security/overview.md @@ -53,7 +53,7 @@ Provedor IaaS | Link | Alibaba Cloud | https://www.alibabacloud.com/trust-center | Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | -Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html | +Huawei Cloud | https://www.huaweicloud.com/intl/pt-br/securecenter/overallsafety | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | Oracle Cloud Infrastructure | https://www.oracle.com/security/ | diff --git a/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html index e6746bfa8d..9e3e00bbb9 100644 --- a/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -267,7 +267,7 @@ description: |- Para ver a saída da aplicação, execute uma requisição com o comando curl:

-

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

+

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

A URL é a rota para a API do Pod.

diff --git a/content/zh-cn/blog/_posts/2023-05-15-kubernetes-1-27-updates-on-speeding-up-pod-startup.md b/content/zh-cn/blog/_posts/2023-05-15-kubernetes-1-27-updates-on-speeding-up-pod-startup.md index b617c0c576..d72b09ab6a 100644 --- a/content/zh-cn/blog/_posts/2023-05-15-kubernetes-1-27-updates-on-speeding-up-pod-startup.md +++ b/content/zh-cn/blog/_posts/2023-05-15-kubernetes-1-27-updates-on-speeding-up-pod-startup.md @@ -140,7 +140,7 @@ More detials can be found in the KEP and the pull requ ## Event triggered updates to container status `Evented PLEG` (PLEG is short for "Pod Lifecycle Event Generator") is set to be in beta for v1.27, -Kubernetes offers two ways for the kubelet to detect Pod lifecycle events, such as a the last +Kubernetes offers two ways for the kubelet to detect Pod lifecycle events, such as the last process in a container shutting down. In Kubernetes v1.27, the _event based_ mechanism has graduated to beta but remains disabled by default. If you do explicitly switch to event-based lifecycle change detection, @@ -190,7 +190,7 @@ CGroup V2 时的内存质量。尽管此特性门控有一定的好处，但如 Kubelet 配置现在包括 `memoryThrottlingFactor`。该因子乘以内存限制或节点可分配内存， -可以设置 cgroupv2 memory.high 值来执行 MemoryQoS。 +可以设置 cgroupv2 `memory.high` 值来执行 MemoryQoS。 减小该因子将为容器 cgroup 设置较低的上限，同时增加了回收压力。 提高此因子将减少回收压力。默认值最初为 0.8，并将在 Kubernetes v1.27 中更改为 0.9。 调整此参数可以减少此特性对 Pod 启动速度的潜在影响。 @@ -226,7 +226,7 @@ container startup by mounting volumes with the correct SELinux label instead of on the volumes recursively. Further details can be found in the KEP . To identify the cause of slow pod startup, analyzing metrics and logs can be helpful. Other -factorsthat may impact pod startup include container runtime, disk speed, CPU and memory +factors that may impact pod startup include container runtime, disk speed, CPU and memory resources on the node. --> SELinux 挂载选项重标记功能在 v1.27 中升至 Beta 版本。 diff --git a/content/zh-cn/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md b/content/zh-cn/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md new file mode 100644 index 0000000000..0eba3172ba --- /dev/null +++ b/content/zh-cn/blog/_posts/2023-08-15-non-graceful-node-shutdown-to-ga.md @@ -0,0 +1,192 @@ +--- +layout: blog +title: "Kubernetes 1.28: 节点非体面关闭进入 GA 阶段（正式发布）" +date: 2023-08-15T10:00:00-08:00 +slug: kubernetes-1-28-non-graceful-node-shutdown-GA +--- + + + + +**作者：** Xing Yang (VMware) and Ashutosh Kumar (Elastic) + +**译者：** Xin Li (Daocloud) + + +Kubernetes 节点非体面关闭特性现已在 Kubernetes v1.28 中正式发布。 + +此特性在 Kubernetes v1.24 中作为 [Alpha](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown) +特性引入，并在 Kubernetes v1.26 中转入 [Beta](https://kubernetes.io/blog/2022/12/16/kubernetes-1-26-non-graceful-node-shutdown-beta/) +阶段。如果原始节点意外关闭或最终处于不可恢复状态（例如硬件故障或操作系统无响应）， +此特性允许有状态工作负载在不同节点上重新启动。 + + +## 什么是节点非体面关闭 + +在 Kubernetes 集群中，节点可能会按计划正常关闭，也可能由于断电或其他外部原因而意外关闭。 +如果节点在关闭之前未腾空，则节点关闭可能会导致工作负载失败。节点关闭可以是正常关闭，也可以是非正常关闭。 + + +[节点体面关闭](https://kubernetes.io/blog/2021/04/21/graceful-node-shutdown-beta/)特性允许 +kubelet 在实际关闭之前检测节点关闭事件、正确终止该节点上的 Pod 并释放资源。 + + +当节点关闭但 kubelet 的节点关闭管理器未检测到时，将造成节点非体面关闭。 +对于无状态应用程序来说，节点非体面关闭通常不是问题，但是对于有状态应用程序来说，这是一个问题。 +如果 Pod 停留在关闭节点上并且未在正在运行的节点上重新启动，则有状态应用程序将无法正常运行。 + + +在节点非体面关闭的情况下，你可以在 Node 上手动添加 `out-of-service` 污点。 + +``` +kubectl taint nodes node.kubernetes.io/out-of-service=nodeshutdown:NoExecute +``` + + +如果 Pod 上没有与之匹配的容忍规则，则此污点会触发节点上的 Pod 被强制删除。 +挂接到关闭中的节点的持久卷将被解除挂接，新的 Pod 将在不同的运行节点上成功创建。 + + +**注意：**在应用 out-of-service 污点之前，你必须验证节点是否已经处于关闭或断电状态（而不是在重新启动中）。 + +与 out-of-service 节点有关联的所有工作负载的 Pod 都被移动到新的运行节点， +并且所关闭的节点已恢复之后，你应该删除受影响节点上的污点。 + + +## 稳定版中有哪些新内容 + +随着非正常节点关闭功能提升到稳定状态，特性门控 +`NodeOutOfServiceVolumeDetach` 在 `kube-controller-manager` 上被锁定为 true，并且无法禁用。 + + +Pod GC 控制器中的指标 `force_delete_pods_total` 和 `force_delete_pod_errors_total` +得到增强，以考虑所有 Pod 的强制删除情况。 +指标中会添加一个 "reason"，以指示 Pod 是否因终止、孤儿、因 `out-of-service` +污点而终止或因未计划终止而被强制删除。 + + +Attach Detach Controller 中的指标 `attachdetach_controller_forced_detaches` +中还会添加一个 "reason"，以指示强制解除挂接是由 `out-of-service` 污点还是超时引起的。 + + +## 接下来 + +此特性要求用户手动向节点添加污点以触发工作负载故障转移，并在节点恢复后删除污点。 +未来，我们计划找到方法来自动检测和隔离关闭/失败的节点，并自动将工作负载故障转移到另一个节点。 + + +## 如何了解更多？ + +在[此处](/zh-cn/docs/concepts/architecture/nodes/#non-graceful-node-shutdown)可以查看有关此特性的其他文档。 + + +我们非常感谢所有帮助设计、实现和审查此功能并帮助其从 Alpha、Beta 到稳定版的贡献者： + +* Michelle Au ([msau42](https://github.com/msau42)) +* Derek Carr ([derekwaynecarr](https://github.com/derekwaynecarr)) +* Danielle Endocrimes ([endocrimes](https://github.com/endocrimes)) +* Baofa Fan ([carlory](https://github.com/carlory)) +* Tim Hockin ([thockin](https://github.com/thockin)) +* Ashutosh Kumar ([sonasingh46](https://github.com/sonasingh46)) +* Hemant Kumar ([gnufied](https://github.com/gnufied)) +* Yuiko Mouri ([YuikoTakada](https://github.com/YuikoTakada)) +* Mrunal Patel ([mrunalp](https://github.com/mrunalp)) +* David Porter ([bobbypage](https://github.com/bobbypage)) +* Yassine Tijani ([yastij](https://github.com/yastij)) +* Jing Xu ([jingxu97](https://github.com/jingxu97)) +* Xing Yang ([xing-yang](https://github.com/xing-yang)) + + +此特性是 SIG Storage 和 SIG Node 之间的协作。对于那些有兴趣参与 Kubernetes +存储系统任何部分的设计和开发的人，请加入 Kubernetes 存储特别兴趣小组（SIG）。 +对于那些有兴趣参与支持 Pod 和主机资源之间受控交互的组件的设计和开发，请加入 Kubernetes Node SIG。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/addons.md b/content/zh-cn/docs/concepts/cluster-administration/addons.md index 6f0e294283..522598aac6 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/addons.md +++ b/content/zh-cn/docs/concepts/cluster-administration/addons.md @@ -67,6 +67,7 @@ Add-on 扩展了 Kubernetes 的功能。 并且可以使用与网络寻址分离的基于身份的安全模型在 L3 至 L7 上实施网络策略。 Cilium 可以作为 kube-proxy 的替代品；它还提供额外的、可选的可观察性和安全功能。 Cilium 是一个[孵化级别的 CNCF 项目](https://www.cncf.io/projects/cilium/)。 + ## 可视化管理 {#visualization-and-control} * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 Web 控制台界面。 -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具， - 用于查看你的容器、Pod、服务等。请和一个 [Weave Cloud 账号](https://cloud.weave.works/) 一起使用， - 或者自己运行 UI。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) + 是一个可视化工具，用于查看你的容器、Pod、服务等。 -此功能特性由 `ImmutableEphemeralVolumes` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。 你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。 例如： diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/_index.md b/content/zh-cn/docs/concepts/overview/working-with-objects/_index.md index c612d8bfb3..dccc90d015 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/_index.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/_index.md @@ -157,7 +157,7 @@ Here's an example `.yaml` file that shows the required fields and object spec fo --> 这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象 `spec`： -{{< codenew file="application/deployment.yaml" >}} +{{< code file="application/deployment.yaml" >}} 以及一个声明 CPU 资源请求为 `700m` 但未声明限制值的 Pod： -{{< codenew file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" >}} +{{% code file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" %}} 如果你同时设置了 `request` 和 `limit`，那么即使使用相同的 `LimitRange`，新 Pod 也会被成功调度： -{{< codenew file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" >}} +{{% code file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}} ## 节点标签 {#built-in-node-labels} 与很多其他 Kubernetes 对象类似，节点也有[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 你可以[手动地添加标签](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。 -Kubernetes 也会为集群中所有节点添加一些标准的标签。 -参见[常用的标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)以了解常见的节点标签。 +Kubernetes 也会为集群中所有节点添加一些[标准的标签](/zh-cn/docs/reference/node/node-labels/)。 {{< note >}} | 操作符 | 行为 | | :------------: | :-------------: | -| `Gt` | 提供的值将被解析为整数，并且该整数小于等于通过解析此选择算符命名的标签的值所得到的整数 | -| `Lt` | 提供的值将被解析为整数，并且该整数大于等于通过解析此选择算符命名的标签的值所得到的整数 | +| `Gt` | 提供的值将被解析为整数，并且该整数小于通过解析此选择算符命名的标签的值所得到的整数 | +| `Lt` | 提供的值将被解析为整数，并且该整数大于通过解析此选择算符命名的标签的值所得到的整数 | {{}} 以下是具有自定义 DNS 设置的 Pod 示例： -{{< codenew file="service/networking/custom-dns.yaml" >}} +{{% code file="service/networking/custom-dns.yaml" %}} 这将需要一个如下所示的 Ingress： -{{< codenew file="service/networking/simple-fanout-example.yaml" >}} +{{% code file="service/networking/simple-fanout-example.yaml" %}} 1. 删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产 - （例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）在 PV 删除之后仍然存在。 + （例如 AWS EBS 或 GCE PD 卷）在 PV 删除之后仍然存在。 1. 根据情况，手动清除所关联的存储资产上的数据。 1. 手动删除所关联的存储资产。 @@ -359,8 +359,8 @@ the same storage asset definition. For volume plugins that support the `Delete` reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated -storage asset in the external infrastructure, such as an AWS EBS, GCE PD, -Azure Disk, or Cinder volume. Volumes that were dynamically provisioned +storage asset in the external infrastructure, such as an AWS EBS or GCE PD volume. +Volumes that were dynamically provisioned inherit the [reclaim policy of their StorageClass](#reclaim-policy), which defaults to `Delete`. The administrator should configure the StorageClass according to users' expectations; otherwise, the PV must be edited or @@ -370,8 +370,7 @@ patched after it is created. See #### 删除（Delete） {#delete} 对于支持 `Delete` 回收策略的卷插件，删除动作会将 PersistentVolume 对象从 -Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或 -Cinder 卷）中移除所关联的存储资产。 +Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS 或 GCE PD 卷）中移除所关联的存储资产。 动态制备的卷会继承[其 StorageClass 中设置的回收策略](#reclaim-policy)， 该策略默认为 `Delete`。管理员需要根据用户的期望来配置 StorageClass； 否则 PV 卷被创建之后必须要被编辑或者修补。 @@ -616,15 +615,20 @@ the following types of volumes: --> 现在，对扩充 PVC 申领的支持默认处于被启用状态。你可以扩充以下类型的卷： -* azureDisk -* azureFile -* awsElasticBlockStore -* cinder （已弃用） + +* azureFile（已弃用） +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume（已弃用） +* gcePersistentDisk（已弃用） +* rbd +* portworxVolume（已弃用） 以下的持久卷已被弃用。这意味着当前仍是支持的，但是 Kubernetes 将来的发行版会将其移除。 -* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore) - AWS 弹性块存储（EBS） - （于 v1.17 **弃用**） -* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk) - Azure Disk - （于 v1.19 **弃用**） * [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) - Azure File （于 v1.21 **弃用**） -* [`cinder`](/zh-cn/docs/concepts/storage/volumes/#cinder) - Cinder（OpenStack 块存储）（于 v1.18 **弃用**） * [`flexVolume`](/zh-cn/docs/concepts/storage/volumes/#flexVolume) - FlexVolume （于 v1.23 **弃用**） * [`gcePersistentDisk`](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk （于 v1.17 **弃用**） @@ -922,6 +915,12 @@ This means that support is still available but will be removed in a future Kuber | 卷插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod | | :--- | :---: | :---: | :---: | - | -| AWSElasticBlockStore | ✓ | - | - | - | | AzureFile | ✓ | ✓ | ✓ | - | -| AzureDisk | ✓ | - | - | - | | CephFS | ✓ | ✓ | ✓ | - | -| Cinder | ✓ | - | ([如果多次挂接卷可用](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes)) | - | | CSI | 取决于驱动 | 取决于驱动 | 取决于驱动 | 取决于驱动 | | FC | ✓ | ✓ | - | - | | FlexVolume | ✓ | ✓ | 取决于驱动 | - | @@ -1213,11 +1229,9 @@ Current reclaim policies are: * Retain -- manual reclamation * Recycle -- basic scrub (`rm -rf /thevolume/*`) -* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, - or OpenStack Cinder volume is deleted +* Delete -- associated storage asset such as AWS EBS or GCE PD volume is deleted -Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, -and Cinder volumes support deletion. +Currently, only NFS and HostPath support recycling. AWS EBS and GCE PD volumes support deletion. --> ### 回收策略 {#reclaim-policy} @@ -1225,10 +1239,10 @@ and Cinder volumes support deletion. * Retain -- 手动回收 * Recycle -- 基本擦除 (`rm -rf /thevolume/*`) -* Delete -- 诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除 +* Delete -- 诸如 AWS EBS 或 GCE PD 卷这类关联存储资产也被删除 目前，仅 NFS 和 HostPath 支持回收（Recycle）。 -AWS EBS、GCE PD、Azure Disk 和 Cinder 卷都支持删除（Delete）。 +AWS EBS 和 GCE PD 卷支持删除（Delete）。 以下卷类型支持挂载选项： -* `awsElasticBlockStore` -* `azureDisk` * `azureFile` * `cephfs` -* `cinder`（于 v1.18 **弃用**） * `gcePersistentDisk` * `iscsi` * `nfs` @@ -1285,15 +1296,11 @@ it will become fully deprecated in a future Kubernetes release. {{< note >}} 对大多数类型的卷而言，你不需要设置节点亲和性字段。 -[AWS EBS](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore)、 -[GCE PD](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) 和 -[Azure Disk](/zh-cn/docs/concepts/storage/volumes/#azuredisk) 卷类型都能自动设置相关字段。 +[GCE PD](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) 卷类型能自动设置相关字段。 你需要为 [local](/zh-cn/docs/concepts/storage/volumes/#local) 卷显式地设置此属性。 {{< /note >}} @@ -1644,14 +1651,20 @@ applicable: --> 以下卷插件支持原始块卷，包括其动态制备（如果支持的话）的卷： -* AWSElasticBlockStore -* AzureDisk + * CSI * FC（光纤通道） * GCEPersistentDisk * iSCSI * Local 卷 -* OpenStack Cinder * RBD（Ceph 块设备） * VsphereVolume diff --git a/content/zh-cn/docs/concepts/storage/storage-classes.md b/content/zh-cn/docs/concepts/storage/storage-classes.md index cb023d47a7..44f0961022 100644 --- a/content/zh-cn/docs/concepts/storage/storage-classes.md +++ b/content/zh-cn/docs/concepts/storage/storage-classes.md @@ -38,9 +38,9 @@ systems. --> ## 介绍 {#introduction} -StorageClass 为管理员提供了描述存储 "类" 的方法。 +StorageClass 为管理员提供了描述存储"类"的方法。 不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 -Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为 "配置文件"。 +Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为"配置文件"。 StorageClass 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。 -当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数，一旦创建了对象就不能再对其更新。 +当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数， +一旦创建了对象就不能再对其更新。 -以下插件支持动态制备的 `WaitForFirstConsumer` 模式: +以下插件支持动态制备的 `WaitForFirstConsumer` 模式： -- [AWSElasticBlockStore](#aws-ebs) - [GCEPersistentDisk](#gce-pd) -- [AzureDisk](#azure-disk) -- `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见 +- `type`：`io1`、`gp2`、`sc1`、`st1`。详细信息参见 [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。 -- `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`， +- `zone`（已弃用）：AWS 区域。如果没有指定 `zone` 和 `zones`， 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 `zone` 和 `zones` 参数不能同时使用。 -- `zones`(弃用)：以逗号分隔的 AWS 区域列表。 +- `zones`（已弃用）：以逗号分隔的 AWS 区域列表。 如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 `zone`和`zones`参数不能同时使用。 - `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。 @@ -484,7 +475,7 @@ parameters: 这里需要输入一个字符串，即 `"10"`，而不是 `10`。 - `fsType`：受 Kubernetes 支持的文件类型。默认值：`"ext4"`。 - `encrypted`：指定 EBS 卷是否应该被加密。合法值为 `"true"` 或者 `"false"`。 - 这里需要输入字符串，即 `"true"`, 而非 `true`。 + 这里需要输入字符串，即 `"true"`，而非 `true`。 - `kmsKeyId`：可选。加密卷时使用密钥的完整 Amazon 资源名称。 如果没有提供，但 `encrypted` 值为 true，AWS 生成一个密钥。关于有效的 ARN 值，请参阅 AWS 文档。 @@ -524,13 +515,13 @@ parameters: - `replication-type`: `none` or `regional-pd`. Default: `none`. --> - `type`：`pd-standard` 或者 `pd-ssd`。默认：`pd-standard` -- `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`， +- `zone`（已弃用）：GCE 区域。如果没有指定 `zone` 和 `zones`， 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。 `zone` 和 `zones` 参数不能同时使用。 -- `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`， +- `zones`（已弃用）：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`， 通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。 `zone` 和 `zones` 参数不能同时使用。 -- `fstype`：`ext4` 或 `xfs`。 默认：`ext4`。宿主机操作系统必须支持所定义的文件系统类型。 +- `fstype`：`ext4` 或 `xfs`。默认：`ext4`。宿主机操作系统必须支持所定义的文件系统类型。 - `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。 -- `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮转调度。 - -{{< note >}} -{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} - -OpenStack 的内部驱动已经被弃用。请使用 -[OpenStack 的外部云驱动](https://github.com/kubernetes/cloud-provider-openstack)。 -{{< /note >}} - ### vSphere {#vsphere} #### vCP 制备器 {#vcp-provisioner} -以下示例使用 VMware Cloud Provider (vCP) StorageClass 制备器。 +以下示例使用 VMware Cloud Provider（vCP）StorageClass 制备器。 谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 -Kubernetes 需要尊重这些限制。 否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。 +Kubernetes 需要尊重这些限制。否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。 @@ -108,7 +108,7 @@ Dynamic volume limits are supported for following volume types. For volumes managed by in-tree volume plugins, Kubernetes automatically determines the Node type and enforces the appropriate maximum number of volumes for the node. For example: --> -对于由内建插件管理的卷，Kubernetes 会自动确定节点类型并确保节点上可关联的卷数目合规。 例如： +对于由内建插件管理的卷，Kubernetes 会自动确定节点类型并确保节点上可关联的卷数目合规。例如： * 在 -Google Compute Engine环境中, -[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将127个卷关联到节点。 + Google Compute Engine环境中， + [根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将 127 个卷关联到节点。 * 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷关联到节点。 -对于 ec2 上的其他实例类型 -Amazon Elastic Compute Cloud (EC2), -Kubernetes 允许 39 个卷关联至节点。 + 对于 ec2 上的其他实例类型 + Amazon Elastic Compute Cloud (EC2)， + Kubernetes 允许 39 个卷关联至节点。 * 在 Azure 环境中, 根据节点类型，最多 64 个磁盘可以关联至一个节点。 -更多详细信息，请参阅[Azure 虚拟机的数量大小](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes)。 + 更多详细信息，请参阅 [Azure 虚拟机的数量大小](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes)。 * 如果 CSI 存储驱动程序（使用 `NodeGetInfo` ）为节点通告卷数上限，则 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} 将遵守该限制值。 -参考 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) 获取更多详细信息。 + 参考 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) 获取更多详细信息。 * 对于由已迁移到 CSI 驱动程序的树内插件管理的卷，最大卷数将是 CSI 驱动程序报告的卷数。 - - diff --git a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md index 0c8da44608..6359ff0e94 100644 --- a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md +++ b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md @@ -25,8 +25,8 @@ and report them as events on {{< glossary_tooltip text="PVCs" term_id="persisten or {{< glossary_tooltip text="Pods" term_id="pod" >}}. --> {{< glossary_tooltip text="CSI" term_id="csi" >}} 卷健康监测支持 CSI 驱动从底层的存储系统着手， -探测异常的卷状态，并以事件的形式上报到 {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} -或 {{< glossary_tooltip text="Pods" term_id="pod" >}}. +探测异常的卷状态，并以事件的形式上报到 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}} +或 {{< glossary_tooltip text="Pod" term_id="pod" >}}. @@ -46,7 +46,7 @@ an event will be reported on the related {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC) when an abnormal volume condition is detected on a CSI volume. --> -Kubernetes _卷健康监测_ 是 Kubernetes 容器存储接口（CSI）实现的一部分。 +Kubernetes **卷健康监测**是 Kubernetes 容器存储接口（CSI）实现的一部分。 卷健康监测特性由两个组件实现：外部健康监测控制器和 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}。 如果 CSI 驱动器通过控制器的方式支持卷健康监测特性，那么只要在 CSI 卷上监测到异常卷状态，就会在 @@ -79,7 +79,8 @@ is healthy. For more information, please check 此外，卷运行状况信息作为 Kubelet VolumeStats 指标公开。 添加了一个新的指标 kubelet_volume_stats_health_status_abnormal。 该指标包括两个标签：`namespace` 和 `persistentvolumeclaim`。 -计数为 1 或 0。1 表示卷不正常，0 表示卷正常。更多信息请访问[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)。 +计数为 1 或 0。1 表示卷不正常，0 表示卷正常。更多信息请访问 +[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)。 下面是一个定义了 `podFailurePolicy` 的 Job 的清单： -{{< codenew file="/controllers/job-pod-failure-policy-example.yaml" >}} +{{% code file="/controllers/job-pod-failure-policy-example.yaml" %}} -如果 Job 是在特性门控 `JobTrackingWithFinalizers` 被禁用时创建的，即使你将控制面升级到 1.26， -控制面也不会使用 Finalizer 跟踪 Job。 -{{< /note >}} - 控制面会跟踪属于任何 Job 的 Pod，并通知是否有任何这样的 Pod 被从 API 服务器中移除。 为了实现这一点，Job 控制器创建的 Pod 带有 Finalizer `batch.kubernetes.io/job-tracking`。 控制器只有在 Pod 被记入 Job 状态后才会移除 Finalizer，允许 Pod 可以被其他控制器或用户移除。 -在升级到 Kubernetes 1.26 之前或在启用特性门控 `JobTrackingWithFinalizers` -之前创建的 Job 被跟踪时不使用 Pod Finalizer。 -Job {{< glossary_tooltip term_id="controller" text="控制器" >}}仅根据集群中存在的 Pod -更新 `succeeded` 和 `failed` Pod 的状态计数器。如果 Pod 被从集群中删除，控制面可能无法跟踪 Job 的进度。 - - -你可以根据检查 Job 是否含有 `batch.kubernetes.io/job-tracking` 注解， -来确定控制面是否正在使用 Pod Finalizer 追踪 Job。 -你**不**应该给 Job 手动添加或删除该注解。 -取而代之的是你可以重新创建 Job 以确保使用 Pod Finalizer 跟踪这些 Job。 - diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md index fbe20e17b5..78ce34407c 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md @@ -113,7 +113,7 @@ Deployment，并在 spec 部分定义你的应用。 --> ## 示例 {#example} -{{< codenew file="controllers/frontend.yaml" >}} +{{% code file="controllers/frontend.yaml" %}} @@ -34,7 +40,7 @@ always up and available. ## 使用 Pod {#using-pods} 下面是一个 Pod 示例，它由一个运行镜像 `nginx:1.14.2` 的容器组成。 -{{< codenew file="pods/simple-pod.yaml" >}} +{{% code file="pods/simple-pod.yaml" %}} + 要创建上面显示的 Pod，请运行以下命令： ```shell @@ -115,10 +114,9 @@ Pod 通常不是直接创建的，而是使用工作负载资源创建的。 ### 用于管理 Pod 的工作负载资源 {#workload-resources-for-managing-pods} 静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。 其主要用途是运行自托管的控制面。 @@ -621,6 +619,7 @@ but cannot be controlled from there. `kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。 +有关更多信息，请参阅[创建静态 Pod](/zh-cn/docs/tasks/configure-pod-container/static-pod) 的指南。 {{< note >}} * 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。 * 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)， @@ -690,8 +689,15 @@ To understand the context for why Kubernetes wraps a common Pod API in other res 或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}） 封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括： + +* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) +* [Borg](https://research.google.com/pubs/pub43438.html) +* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) +* [Omega](https://research.google/pubs/pub41684/) +* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/)。 diff --git a/content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md b/content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md index 531c9ea76d..e7e3ab374c 100644 --- a/content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md @@ -449,13 +449,14 @@ Renders to: {{< /tabs >}} -你可以使用 `{{}}` 短代码将文件内容嵌入代码块中， +## 源代码文件 +你可以使用 `{{}}` 短代码将文件内容嵌入代码块中， 以允许用户下载或复制其内容到他们的剪贴板。 当示例文件的内容是通用的、可复用的，并且希望用户自己尝试使用示例文件时， 可以使用此短代码。 @@ -475,7 +476,7 @@ For example: 如果未提供 `language` 参数，短代码将尝试根据文件扩展名推测编程语言。 ```none -{{}} +{{}} ``` 输出是： -{{< codenew language="yaml" file="application/deployment-scale.yaml" >}} +{{< code language="yaml" file="application/deployment-scale.yaml" >}} 添加新的示例文件（例如 YAML 文件）时，在 `/examples/` 子目录之一中创建该文件，其中 `` 是页面的语言。 -在你的页面的 markdown 文本中，使用 `codenew` 短代码： +在你的页面的 markdown 文本中，使用 `code` 短代码： ```none -{{/example-yaml>" */>}} +{{/example-yaml>" */>}} ``` 其中 `` 是要包含的示例文件的路径，相对于 `examples` 目录。 以下短代码引用位于 `/content/en/examples/configmap/configmaps.yaml` 的 YAML 文件。 ```none -{{}} +{{}} ``` + +传统的 `{{%/* codenew */%}}` 短代码将被替换为 `{{%/* code */%}}`。 +在新文档中使用 `{{%/* code */%}}`。 + diff --git a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md index 8c7bc26093..ba7176c588 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md @@ -204,6 +204,11 @@ the `admissionregistration.k8s.io/v1alpha1` API. {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} + +**类别**：验证。 + +**类别**：验证。 + @@ -238,6 +248,11 @@ required. ### CertificateApproval {#certificateapproval} + +**类别**：验证。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：变更。 + +**类别**：变更。 + +**类别**：变更。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：变更。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：变更和验证。 + +**类别**：变更。 + +**类别**：变更。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：变更。 + +**类别**：验证。 + +**类别**：验证。 + +**类别**：变更和验证。 + ### 优先级 {#priority} +**类别**：变更和验证。 + 优先级准入控制器使用 `priorityClassName` 字段并用整型值填充优先级。 如果找不到优先级，则拒绝 Pod。 ### ResourceQuota {#resourcequota} + +**类别**：验证。 + +**类别**：变更和验证。 + +**类别**：验证。 + {{< feature-state for_k8s_version="v1.27" state="deprecated" >}} {{< caution >}} @@ -1333,6 +1477,11 @@ article details the PodSecurityPolicy historical context and the birth of the ### ServiceAccount {#serviceaccount} + +**类别**：变更和验证。 + +**类别**：变更。 + +**类别**：变更。 + +**类别**：验证。 + +**类别**：验证。 + {{< note >}} @@ -172,6 +172,6 @@ kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test- kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' # 下面的命令可以获得所需的结果 -kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image' +kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).metadata.name' ``` {{< /note >}} diff --git a/content/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1.md b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1.md index ef6a2e4e12..bb94d518dc 100644 --- a/content/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1.md +++ b/content/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1.md @@ -1940,7 +1940,7 @@ A single application container that you want to run within a pod. 如果为 true，则以只读方式挂载，否则（false 或未设置）以读写方式挂载。默认为 false。 - - **volumeMounts.subPath** (boolean) + - **volumeMounts.subPath** (string) 卷中的路径，容器中的卷应该这一路径安装。默认为 ""（卷的根）。 diff --git a/content/zh-cn/docs/reference/labels-annotations-taints/_index.md b/content/zh-cn/docs/reference/labels-annotations-taints/_index.md index c6cced07fc..ac154e1726 100644 --- a/content/zh-cn/docs/reference/labels-annotations-taints/_index.md +++ b/content/zh-cn/docs/reference/labels-annotations-taints/_index.md @@ -83,7 +83,7 @@ Starting from v1.9, this label is deprecated. ### addonmanager.kubernetes.io/mode @@ -785,7 +785,7 @@ For more details, see [Addon-manager](https://github.com/kubernetes/kubernetes/b - `Ignore`：插件资源将被忽略。此模式对于与外接插件管理器不兼容或由其他控制器管理的插件程序非常有用。 有关详细信息，请参见 -[Addon-manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/README.md) +[Addon-manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/README.md)。 Kubernetes 对 Zone 和 Region 的结构做了一些假设： @@ -1540,7 +1540,7 @@ Example: `volume.beta.kubernetes.io/storage-provisioner: "k8s.io/minikube-hostpa Used on: PersistentVolumeClaim This annotation has been deprecated since v1.23. -See [volume.kubernetes.io/storage-provisioner](#volume-kubernetes-io-storage-provisioner) +See [volume.kubernetes.io/storage-provisioner](#volume-kubernetes-io-storage-provisioner). --> ### volume.beta.kubernetes.io/storage-provisioner (已弃用) {#volume-beta-kubernetes-io-storage-provisioner} @@ -1581,7 +1581,7 @@ This annotation has been deprecated. Instead, set the [`storageClassName` field](/docs/concepts/storage/persistent-volumes/#class) for the PersistentVolumeClaim or PersistentVolume. --> -此注解可以为 PersistentVolume (PV) 或 PersistentVolumeClaim (PVC) 指定 +此注解可以为 PersistentVolume（PV）或 PersistentVolumeClaim（PVC）指定 [StorageClass](/zh-cn/docs/concepts/storage/storage-classes/)。 当 `storageClassName` 属性和 `volume.beta.kubernetes.io/storage-class` 注解均被指定时， 注解 `volume.beta.kubernetes.io/storage-class` 将优先于 `storageClassName` 属性。 @@ -1997,7 +1997,7 @@ resource without a class specified will be assigned this default class. 资源将被设置为此默认类。 -### alpha.kubernetes.io/provided-node-ip {#alpha-kubernetes-io-provided-node-ip} +### alpha.kubernetes.io/provided-node-ip (alpha) {#alpha-kubernetes-io-provided-node-ip} 类别：注解 @@ -2094,8 +2094,7 @@ container. 此注解已被弃用。取而代之的是使用 [`kubectl.kubernetes.io/default-container`](#kubectl-kubernetes-io-default-container) 注解。 @@ -2143,11 +2142,8 @@ Example: `batch.kubernetes.io/job-tracking: ""` Used on: Jobs -The presence of this annotation on a Job indicates that the control plane is +The presence of this annotation on a Job used to indicate that the control plane is [tracking the Job status using finalizers](/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers). -The control plane uses this annotation to safely transition to tracking Jobs -using finalizers, while the feature is in development. -You should **not** manually add or remove this annotation. --> ### batch.kubernetes.io/job-tracking (已弃用) {#batch-kubernetes-io-job-tracking} @@ -2158,18 +2154,13 @@ You should **not** manually add or remove this annotation. 用于：Job Job 上存在此注解表明控制平面正在[使用 Finalizer 追踪 Job](/zh-cn/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers)。 -控制平面使用此注解来安全地转换为使用 Finalizer 追踪 Job，而此特性正在开发中。 -你 **不** 可以手动添加或删除此注解。 -{{< note >}} -从 Kubernetes 1.26 开始，该注解被弃用。 -Kubernetes 1.27 及以上版本将忽略此注解，并始终使用 Finalizer 追踪 Job。 -{{< /note >}} +添加或删除此注解不再有效（Kubernetes v1.27 及更高版本）， +所有 Job 均通过 Finalizer 进行追踪。 ## 使用带 retainKeys 策略的策略合并 patch 更新 Deployment {#use-strategic-merge-patch-to-update-a-deployment-using-the-retainkeys-strategy} -{{% codenew file="application/deployment-retainkeys.yaml" %}} +{{% code file="application/deployment-retainkeys.yaml" %}} 使用 minAvailable 的 PDB 示例： -{{% codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" %}} +{{% code file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" %}} 使用 maxUnavailable 的 PDB 示例： -{{% codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" %}} +{{% code file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" %}} 除了使用 `kubectl autoscale` 命令，也可以使用以下清单以声明方式创建 HorizontalPodAutoscaler： -{{% codenew file="application/hpa/php-apache.yaml" %}} +{{% code file="application/hpa/php-apache.yaml" %}} 在低于 Debian 12 和 Ubuntu 22.04 的发行版本中，`/etc/apt/keyrings` 默认不存在。 -如有需要，你可以创建此目录，并将其设置为对所有人可读，但仅对管理员可写。 +可以使用 `sudo mkdir -m 755 /etc/apt/keyrings` 来创建。 {{< /note >}} {{% /tab %}} diff --git a/content/zh-cn/docs/tasks/tools/install-kubectl-windows.md b/content/zh-cn/docs/tasks/tools/install-kubectl-windows.md index ef83219190..f6046b9d1c 100644 --- a/content/zh-cn/docs/tasks/tools/install-kubectl-windows.md +++ b/content/zh-cn/docs/tasks/tools/install-kubectl-windows.md @@ -42,7 +42,7 @@ The following methods exist for installing kubectl on Windows: 在 Windows 系统中安装 kubectl 有如下几种方法： - @@ -54,14 +54,10 @@ The following methods exist for installing kubectl on Windows: --> ### 用 curl 在 Windows 上安装 kubectl {#install-kubectl-binary-with-curl-on-windows} - - 1. 下载最新补丁版 {{< skew currentVersion >}}： [kubectl {{< skew currentPatchVersion >}}](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe)。 @@ -88,7 +84,7 @@ The following methods exist for installing kubectl on Windows: Download the `kubectl` checksum file: --> 2. 验证该可执行文件（可选步骤） - + 下载 `kubectl` 校验和文件： ```powershell @@ -103,6 +99,7 @@ The following methods exist for installing kubectl on Windows: + - 在命令行环境中，手工对比 `CertUtil` 命令的输出与校验和文件： ```cmd @@ -114,18 +111,18 @@ The following methods exist for installing kubectl on Windows: - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: --> + - 用 PowerShell 自动验证，用运算符 `-eq` 来直接取得 `True` 或 `False` 的结果： ```powershell $(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256) ``` - - 3. 将 `kubectl` 二进制文件夹追加或插入到你的 `PATH` 环境变量中。 4. 测试一下，确保此 `kubectl` 的版本和期望版本一致： @@ -161,7 +158,7 @@ The following methods exist for installing kubectl on Windows: ``` {{< note >}} - 2. 测试一下，确保安装的是最新版本： @@ -213,7 +210,7 @@ installer or remove the Docker Desktop's `kubectl`. kubectl version --client ``` - 3. 导航到你的 home 目录： @@ -223,7 +220,7 @@ installer or remove the Docker Desktop's `kubectl`. cd ~ ``` - 4. 创建目录 `.kube`： @@ -241,7 +238,7 @@ installer or remove the Docker Desktop's `kubectl`. cd .kube ``` - 6. 配置 kubectl，以接入远程的 Kubernetes 集群： @@ -251,20 +248,20 @@ installer or remove the Docker Desktop's `kubectl`. ``` {{< note >}} - 编辑配置文件，你需要先选择一个文本编辑器，比如 Notepad。 {{< /note >}} - ## 验证 kubectl 配置 {#verify-kubectl-configration} {{< include "included/verify-kubectl.md" >}} - + - 用提示的命令对 `CertUtil` 的输出和下载的校验和文件进行手动比较。 - + ```cmd CertUtil -hashfile kubectl-convert.exe SHA256 type kubectl-convert.exe.sha256 @@ -336,7 +334,7 @@ kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以 --> - 使用 PowerShell `-eq` 操作使验证自动化，获得 `True` 或者 `False` 的结果： - + ```powershell $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) ``` diff --git a/content/zh-cn/docs/tutorials/services/connect-applications-service.md b/content/zh-cn/docs/tutorials/services/connect-applications-service.md index 57bb46162f..1be3682f11 100644 --- a/content/zh-cn/docs/tutorials/services/connect-applications-service.md +++ b/content/zh-cn/docs/tutorials/services/connect-applications-service.md @@ -55,7 +55,7 @@ Create an nginx Pod, and note that it has a container port specification: 我们在之前的示例中已经做过，然而让我们以网络连接的视角再重做一遍。 创建一个 Nginx Pod，注意其中包含一个容器端口的规约： -{{< codenew file="service/networking/run-my-nginx.yaml" >}} +{{< code file="service/networking/run-my-nginx.yaml" >}} 这等价于使用 `kubectl create -f` 命令及如下的 yaml 文件创建： -{{< codenew file="service/networking/nginx-svc.yaml" >}} +{{< code file="service/networking/nginx-svc.yaml" >}} 以下是你在运行 make 时遇到问题时要遵循的手动步骤（例如，在 Windows 上）： + ```shell # 创建公钥和相对应的私钥 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" @@ -461,7 +470,7 @@ cat /d/tmp/nginx.key | base64 Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. --> -使用前面命令的输出来创建 yaml 文件，如下所示。 base64 编码的值应全部放在一行上。 +如下所示，使用上述命令的输出来创建 yaml 文件。base64 编码的值应全部放在一行上。 ```yaml apiVersion: "v1" @@ -495,7 +504,7 @@ in the secret, and the Service, to expose both ports (80 and 443): --> 现在修改 Nginx 副本以启动一个使用 Secret 中的证书的 HTTPS 服务器以及相应的用于暴露其端口（80 和 443）的 Service： -{{< codenew file="service/networking/nginx-secure-app.yaml" >}} +{{< code file="service/networking/nginx-secure-app.yaml" >}} -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: nginx-deployment - labels: - app: nginx -spec: - replicas: 1 - selector: - matchLabels: - app: nginx - template: - metadata: - labels: - app: nginx - spec: - terminationGracePeriodSeconds: 120 # 超长优雅期 - containers: - - name: nginx - image: nginx:latest - ports: - - containerPort: 80 - lifecycle: - preStop: - exec: - # 实际生产环境中的 Pod 终止可能需要执行任何时长，但不会超过 terminationGracePeriodSeconds。 - # 在本例中，只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间， - # 在 120 秒时容器将被强制终止。 - # 请注意，在所有这些时间点 nginx 都将继续处理请求。 - command: [ - "/bin/sh", "-c", "sleep 180" - ] +现在使用以上文件创建 Deployment Pod 和 Service： ---- - -apiVersion: v1 -kind: Service -metadata: - name: nginx-service -spec: - selector: - app: nginx - ports: - - protocol: TCP - port: 80 - targetPort: 80 +```shell +kubectl apply -f pod-with-graceful-termination.yaml +kubectl apply -f explore-graceful-termination-nginx.yaml ``` @@ -222,6 +223,7 @@ You can then run a command inside that Pod: # 从 “kubectl run” 的终端中运行 ip addr ``` + ``` 1: lo: mtu 65536 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 @@ -303,6 +305,7 @@ port allocated above. ```shell for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done ``` + @@ -386,6 +389,7 @@ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i cli The output is similar to: --> 输出类似于： + ``` client_address=198.51.100.79 ``` @@ -447,6 +451,7 @@ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-p The output is: --> 输出为： + ``` service/loadbalancer exposed ``` @@ -455,13 +460,16 @@ service/loadbalancer exposed Print out the IP addresses of the Service: --> 打印 Service 的 IP 地址： + ```console kubectl get svc loadbalancer ``` + 输出类似于： + ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m @@ -471,13 +479,16 @@ loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m Next, send a request to this Service's external-ip: --> 接下来，发送请求到 Service 的 的外部 IP（External-IP）： + ```shell curl 203.0.113.140 ``` + 输出类似于： + ``` CLIENT VALUES: client_address=10.240.0.5 @@ -524,6 +535,7 @@ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort The output is similar to this: --> 输出类似于： + ```yaml healthCheckNodePort: 32122 ``` @@ -542,6 +554,7 @@ kubectl get pod -o wide -l app=source-ip-app The output is similar to this: --> 输出类似于： + ``` NAME READY STATUS RESTARTS AGE IP NODE source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst @@ -551,10 +564,15 @@ source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180. Use `curl` to fetch the `/healthz` endpoint on various nodes: --> 使用 `curl` 获取各个节点上的 `/healthz` 端点： + + ```shell # 在你选择的节点上本地运行 curl localhost:32122/healthz ``` + ``` 1 Service Endpoints found ``` @@ -563,10 +581,15 @@ curl localhost:32122/healthz On a different node you might get a different result: --> 在不同的节点上，你可能会得到不同的结果： + + ```shell # 在你选择的节点上本地运行 curl localhost:32122/healthz ``` + ``` No Service Endpoints Found ``` @@ -586,10 +609,12 @@ then use `curl` to query the IPv4 address of the load balancer: ```shell curl 203.0.113.140 ``` + 输出类似于： + ``` CLIENT VALUES: client_address=198.51.100.79 diff --git a/content/zh-cn/docs/tutorials/stateless-application/guestbook.md b/content/zh-cn/docs/tutorials/stateless-application/guestbook.md index 7f10de59eb..ff8d93ea9e 100644 --- a/content/zh-cn/docs/tutorials/stateless-application/guestbook.md +++ b/content/zh-cn/docs/tutorials/stateless-application/guestbook.md @@ -85,7 +85,7 @@ The manifest file, included below, specifies a Deployment controller that runs a --> 下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 Redis Pod 副本。 -{{< codenew file="application/guestbook/redis-leader-deployment.yaml" >}} +{{< code file="application/guestbook/redis-leader-deployment.yaml" >}} ### 创建 Guestbook 前端 Deployment {#creating-the-guestbook-frontend-deployment} -{{< codenew file="application/guestbook/frontend-deployment.yaml" >}} +{{< code file="application/guestbook/frontend-deployment.yaml" >}} -| 月度补丁发布 | Cherry Pick 截止日期 | 目标日期 | -|------------|------------------|------------| -| 2023 年 7 月 | 2023-07-07 | 2023-07-12 | -| 2023 年 8 月 | 2023-08-04 | 2023-08-09 | -| 2023 年 9 月 | 2023-09-08 | 2023-09-13 | +| 月度补丁发布 | Cherry Pick 截止日期 | 目标日期 | +|--------------|---------------------|------------| +| 2023 年 8 月 | 2023-08-04 | 2023-08-09 | +| 2023 年 9 月 | 2023-09-08 | 2023-09-13 | +| 2023 年 10 月 | 2023-10-13 | 2023-10-18 | +| 2023 年 11 月 | N/A | N/A | +| 2023 年 12 月 | 2023-12-01 | 2023-12-06 | + + +**注意：**由于与 KubeCon NA 2023 时间冲突以及缺少可用的 Release Manager 和 +Google Build Admin，我们决定在 11 月跳过补丁版本发布。而是在 12 月初发布补丁版本。