From 0ffe9f327baef04177d5f7d07961a6671417d5f5 Mon Sep 17 00:00:00 2001 From: Guangwen Feng Date: Fri, 12 Nov 2021 11:40:56 +0800 Subject: [PATCH 001/145] [ja] Remove ^H character Signed-off-by: Guangwen Feng --- content/ja/docs/tasks/network/validate-dual-stack.md | 4 ++-- content/ja/docs/tutorials/clusters/apparmor.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/network/validate-dual-stack.md b/content/ja/docs/tasks/network/validate-dual-stack.md index 9ab51d8701..1859d1e408 100644 --- a/content/ja/docs/tasks/network/validate-dual-stack.md +++ b/content/ja/docs/tasks/network/validate-dual-stack.md @@ -135,7 +135,7 @@ status: loadBalancer: {} ``` -`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 +`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 {{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}} @@ -173,7 +173,7 @@ status: loadBalancer: {} ``` -`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 +`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} diff --git a/content/ja/docs/tutorials/clusters/apparmor.md b/content/ja/docs/tutorials/clusters/apparmor.md index 5ee0201d71..f1b4eb33ac 100644 --- a/content/ja/docs/tutorials/clusters/apparmor.md +++ b/content/ja/docs/tutorials/clusters/apparmor.md @@ -35,7 +35,7 @@ AppArmorを利用すれば、コンテナに許可することを制限したり gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` -2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。 +2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。 ```shell cat /sys/module/apparmor/parameters/enabled From 49d19584c6e97d332e301f2da3598acc4e696ea1 Mon Sep 17 00:00:00 2001 From: ptux Date: Thu, 18 Nov 2021 00:09:58 +0900 Subject: [PATCH 002/145] translate distribute-credentials-secure into Japanese --- .../distribute-credentials-secure.md | 260 ++++++++++++++++++ .../pod-multiple-secret-env-variable.yaml | 19 ++ .../pods/inject/pod-secret-envFrom.yaml | 11 + .../pod-single-secret-env-variable.yaml | 14 + 4 files changed, 304 insertions(+) create mode 100644 content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md create mode 100644 content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml create mode 100644 content/ja/examples/pods/inject/pod-secret-envFrom.yaml create mode 100644 content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md new file mode 100644 index 0000000000..772ada5e20 --- /dev/null +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -0,0 +1,260 @@ +--- +title: Secretsで安全にクレデンシャルを配布する +content_type: task +weight: 50 +min-kubernetes-server-version: v1.6 +--- + + +このページでは、パスワードや暗号化キーなどの機密データをPodに安全に注入する方法を紹介します。 + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +### 秘密データをbase64でエンコードする + +ユーザー名 `my-app` とパスワード `39528$vdg7Jb` の2つの秘密データが必要だとします。 +まず、base64エンコーディングツールを使って、ユーザ名とパスワードをbase64表現に変換します。 +ここでは、手軽に入手できるbase64プログラムを使った例を紹介します: + +```shell +echo -n 'my-app' | base64 +echo -n '39528$vdg7Jb' | base64 +``` + +出力結果によると、ユーザ名のbase64表現は `bXktYXBw`で、 +パスワードのbase64表現は `Mzk1MjgkdmRnN0pi` です。 + +{{< caution >}} +OSから信頼されているローカルツールを使用することで、外部ツールのセキュリティリスクを低減することができます。 +{{< /caution >}} + + + + +## Secret を作成する + +以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイル: + +{{< codenew file="pods/inject/secret.yaml" >}} + +1. Secret を作成する + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml + ``` + +1. Secret の情報を取得する + + ```shell + kubectl get secret test-secret + ``` + + 出力: + + ``` + NAME TYPE DATA AGE + test-secret Opaque 2 1m + ``` + +1. Secret の詳細な情報を取得する: + + ```shell + kubectl describe secret test-secret + ``` + + 出力: + + ``` + Name: test-secret + Namespace: default + Labels: + Annotations: + + Type: Opaque + + Data + ==== + password: 13 bytes + username: 7 bytes + ``` + +### kubectl で Secret を作成する + +base64エンコードの手順を省略したい場合は、`kubectl create secret`コマンドで +同じSecretを作成することができます。 + +例えば: + +```shell +kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' +``` + +先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、 +`kubectl create secret` の方が便利です。 + + +## Volume にある秘密情報をアクセスする Pod を作成する + +これは Pod の作成に使用できる設定ファイルです。 + +{{< codenew file="pods/inject/secret-pod.yaml" >}} + +1. Pod を作成する: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml + ``` + +1. Pod がランニング状態にあるのを確認する: + + ```shell + kubectl get pod secret-test-pod + ``` + + 出力: + ``` + NAME READY STATUS RESTARTS AGE + secret-test-pod 1/1 Running 0 42m + ``` + +1. Pod の中にあるコンテナにシェルを実行する + + ```shell + kubectl exec -i -t secret-test-pod -- /bin/bash + ``` + +1. 秘密のデータは `/etc/secret-volume` にマウントされたボリュームを介してコンテナに公開されます。 + + ディレクトリ `/etc/secret-volume` 中のファイルの一覧を確認する: + ```shell + # Run this in the shell inside the container + ls /etc/secret-volume + ``` + `password`と`username` ２つのファイル名が出力される: + ``` + password username + ``` + +1. `username` と `password` ファイルの中身を表示する: + + ```shell + # Run this in the shell inside the container + echo "$( cat /etc/secret-volume/username )" + echo "$( cat /etc/secret-volume/password )" + + ``` + 出力: + ``` + my-app + 39528$vdg7Jb + ``` + +## Secret でコンテナの環境変数を定義する + +### 単一の Secret でコンテナの環境変数を定義する + +* Secret の中で key-value ペアで環境変数を定義する: + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + ``` + +* Secret で定義された`backend-username`の値をPodの環境変数`SECRET_USERNAME`に割り当てます。 + + {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}} + +* Pod を作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml + ``` + +* コンテナの環境変数 `SECRET_USERNAME` の中身を表示する: + + ```shell + kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' + ``` + + 出力: + ``` + backend-admin + ``` + +### 複数の Secret からコンテナの環境変数を定義する + +* 前述の例と同様に、まず Secret を作成します: + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + kubectl create secret generic db-user --from-literal=db-username='db-admin' + ``` + +* Pod の中で環境変数を定義する: + + {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}} + +* Pod を作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml + ``` + +* コンテナの環境変数を表示する: + + ```shell + kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' + ``` + 出力: + ``` + DB_USERNAME=db-admin + BACKEND_USERNAME=backend-admin + ``` + + +## Secret のすべての key-value ペアを環境変数として設定する + +{{< note >}} +この機能は Kubernetes v1.6 以降から利用可能 +{{< /note >}} + +* 複数 key-value ペアを含む Secret を作成する + + ```shell + kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' + ``` + +* envFromを使用してSecretのすべてのデータをコンテナの環境変数として定義します。Secret のキーが Pod の環境変数名になります。 + + {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} + +* Pod を作成する: + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml + ``` + +* `username` と `password` コンテナの環境変数を表示する + + ```shell + kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' + ``` + + 出力: + ``` + username: my-app + password: 39528$vdg7Jb + ``` + +### 参考文献 + +* [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) +* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + +## {{% heading "whatsnext" %}} + +* [Secrets](/docs/concepts/configuration/secret/) についてもっと知る. +* [Volumes](/docs/concepts/storage/volumes/) について. diff --git a/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml b/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml new file mode 100644 index 0000000000..f285e41932 --- /dev/null +++ b/content/ja/examples/pods/inject/pod-multiple-secret-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envvars-multiple-secrets +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: BACKEND_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username + - name: DB_USERNAME + valueFrom: + secretKeyRef: + name: db-user + key: db-username diff --git a/content/ja/examples/pods/inject/pod-secret-envFrom.yaml b/content/ja/examples/pods/inject/pod-secret-envFrom.yaml new file mode 100644 index 0000000000..eb1d3213ef --- /dev/null +++ b/content/ja/examples/pods/inject/pod-secret-envFrom.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envfrom-secret +spec: + containers: + - name: envars-test-container + image: nginx + envFrom: + - secretRef: + name: test-secret diff --git a/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml b/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml new file mode 100644 index 0000000000..af4cf8732f --- /dev/null +++ b/content/ja/examples/pods/inject/pod-single-secret-env-variable.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: env-single-secret +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username From 22ed7f40a4cbf1911be3d80b65c68c62dcd6f344 Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 19 Nov 2021 23:08:32 +0900 Subject: [PATCH 003/145] overview done --- .../tasks/debug-application-cluster/audit.md | 253 ++++++++++++++++++ 1 file changed, 253 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/audit.md diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md new file mode 100644 index 0000000000..0cac8fed0e --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -0,0 +1,253 @@ +--- +content_type: concept +title: 監査 +--- + + + +Kubernetesの監査はクラスタ内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 +クラスタはユーザー、Kubernetes APIを使用するアプリケーション、 +およびコントロールプレーン自体によって生成されたアクティビティなどを監査します。 + +監査により、クラスタ管理者は以下の質問に答えることができます: + + - what happened? + - when did it happen? + - who initiated it? + - on what did it happen? + - where was it observed? + - from where was it initiated? + - to where was it going? + + + +Audit records begin their lifecycle inside the +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +component. Each request on each stage +of its execution generates an audit event, which is then pre-processed according to +a certain policy and written to a backend. The policy determines what's recorded +and the backends persist the records. The current backend implementations +include logs files and webhooks. + +Each request can be recorded with an associated _stage_. The defined stages are: + +- `RequestReceived` - The stage for events generated as soon as the audit + handler receives the request, and before it is delegated down the handler + chain. +- `ResponseStarted` - Once the response headers are sent, but before the + response body is sent. This stage is only generated for long-running requests + (e.g. watch). +- `ResponseComplete` - The response body has been completed and no more bytes + will be sent. +- `Panic` - Events generated when a panic occurred. + +{{< note >}} +The configuration of an +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +is different from the +[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) +API object. +{{< /note >}} + +The audit logging feature increases the memory consumption of the API server +because some context required for auditing is stored for each request. +Memory consumption depends on the audit logging configuration. + +## Audit policy + +Audit policy defines rules about what events should be recorded and what data +they should include. The audit policy object structure is defined in the +[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy). +When an event is processed, it's +compared against the list of rules in order. The first matching rule sets the +_audit level_ of the event. The defined audit levels are: + +- `None` - don't log events that match this rule. +- `Metadata` - log request metadata (requesting user, timestamp, resource, + verb, etc.) but not request or response body. +- `Request` - log event metadata and request body but not response body. + This does not apply for non-resource requests. +- `RequestResponse` - log event metadata, request and response bodies. + This does not apply for non-resource requests. + +You can pass a file with the policy to `kube-apiserver` +using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. +Note that the `rules` field __must__ be provided in the audit policy file. +A policy with no (0) rules is treated as illegal. + +Below is an example audit policy file: + +{{< codenew file="audit/audit-policy.yaml" >}} + +You can use a minimal audit policy file to log all requests at the `Metadata` level: + +```yaml +# Log all requests at the Metadata level. +apiVersion: audit.k8s.io/v1 +kind: Policy +rules: +- level: Metadata +``` + +If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) +script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script. + +You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) +for details about the fields defined. + +## Audit backends + +Audit backends persist audit events to an external storage. +Out of the box, the kube-apiserver provides two backends: + +- Log backend, which writes events into the filesystem +- Webhook backend, which sends events to an external HTTP API + +In all cases, audit events follow a structure defined by the Kubernetes API in the +[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event). + +{{< note >}} +In case of patches, request body is a JSON array with patch operations, not a JSON object +with an appropriate Kubernetes API object. For example, the following request body is a valid patch +request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`: + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` + +{{< /note >}} + +### Log backend + +The log backend writes audit events to a file in [JSONlines](https://jsonlines.org/) format. +You can configure the log audit backend using the following `kube-apiserver` flags: + +- `--audit-log-path` specifies the log file path that log backend uses to write + audit events. Not specifying this flag disables log backend. `-` means standard out +- `--audit-log-maxage` defined the maximum number of days to retain old audit log files +- `--audit-log-maxbackup` defines the maximum number of audit log files to retain +- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated + +If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath` +to the location of the policy file and log file, so that audit records are persisted. For example: +```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ + --audit-log-path=/var/log/audit.log +``` +then mount the volumes: + +```yaml +... +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false +``` +and finally configure the `hostPath`: + +```yaml +... +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/audit.log + type: FileOrCreate + +``` + +### Webhook backend + +The webhook audit backend sends audit events to a remote web API, which is assumed to +be a form of the Kubernetes API, including means of authentication. You can configure +a webhook audit backend using the following kube-apiserver flags: + +- `--audit-webhook-config-file` specifies the path to a file with a webhook + configuration. The webhook configuration is effectively a specialized + [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). +- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed + request before retrying. Subsequent requests are retried with exponential backoff. + +The webhook config file uses the kubeconfig format to specify the remote address of +the service and credentials used to connect to it. + +## Event batching {#batching} + +Both log and webhook backends support batching. Using webhook as an example, here's the list of +available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag +name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default +throttling is enabled in `webhook` and disabled in `log`. + +- `--audit-webhook-mode` defines the buffering strategy. One of the following: + - `batch` - buffer events and asynchronously process them in batches. This is the default. + - `blocking` - block API server responses on processing each individual event. + - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at the + RequestReceived stage, the whole request to the kube-apiserver fails. + +The following flags are used only in the `batch` mode: + +- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching. + If the rate of incoming events overflows the buffer, events are dropped. +- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch. +- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally + batching events in the queue. +- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated + per second. +- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same + moment if the allowed QPS was underutilized previously. + +## Parameter tuning + +Parameters should be set to accommodate the load on the API server. + +For example, if kube-apiserver receives 100 requests each second, and each request is audited only +on `ResponseStarted` and `ResponseComplete` stages, you should account for ≅200 audit +events being generated each second. Assuming that there are up to 100 events in a batch, +you should set throttling level at least 2 queries per second. Assuming that the backend can take up to +5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events; +that is: 10 batches, or 1000 events. + +In most cases however, the default parameters should be sufficient and you don't have to worry about +setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver +and in the logs to monitor the state of the auditing subsystem. + +- `apiserver_audit_event_total` metric contains the total number of audit events exported. +- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error + during exporting. + +### Log entry truncation {#truncate} + +Both log and webhook backends support limiting the size of events that are logged. +As an example, the following is the list of flags available for the log backend: + +- `audit-log-truncate-enabled` whether event and batch truncating is enabled. +- `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend. +- `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend. + +By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set +`audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature. + +## {{% heading "whatsnext" %}} + +* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). +* Learn more about [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) + and the [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) + resource types by reading the Audit configuration reference. + From 497a07f5f52ee26fc4b68506281ccde8efa949d1 Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 19 Nov 2021 23:49:54 +0900 Subject: [PATCH 004/145] add reference file --- .../kube-apiserver.md | 2535 +++++++++++++++++ .../config-api/apiserver-audit.v1.md | 620 ++++ 2 files changed, 3155 insertions(+) create mode 100644 content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md create mode 100644 content/ja/docs/reference/config-api/apiserver-audit.v1.md diff --git a/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md new file mode 100644 index 0000000000..96d0229b43 --- /dev/null +++ b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -0,0 +1,2535 @@ +--- +title: kube-apiserver +content_type: tool-reference +weight: 30 +auto_generated: true +--- + + + +## {{% heading "synopsis" %}} + + + +Kubernetes API 服务器验证并配置 API 对象的数据， +这些对象包括 pods、services、replicationcontrollers 等。 +API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端， +所有其他组件都通过该前端进行交互。 + +``` +kube-apiserver [flags] +``` + +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
+ +

如果为 true，则将文件目录添加到日志消息的标题中

+
--admission-control-config-file string
+ +

包含准入控制配置的文件。

+
--advertise-address string
+ +

+向集群成员通知 apiserver 消息的 IP 地址。 +这个地址必须能够被集群中其他成员访问。 +如果 IP 地址为空，将会使用 --bind-address， +如果未指定 --bind-address，将会使用主机的默认接口地址。 +

+
--allow-metric-labels stringToString     默认值：[]

+ +允许使用的指标标签到指标值的映射列表。键的格式为 <MetricName>,<LabelName>. +值的格式为 <allowed_value>,<allowed_value>...。 +例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。 +

--allow-privileged
+ +如果为 true, 将允许特权容器。[默认值=false] +
--alsologtostderr
+ +在向文件输出日志的同时，也将日志写到标准输出。 +
--anonymous-auth     默认值：true
+ +启用到 API 服务器的安全端口的匿名请求。 +未被其他认证方法拒绝的请求被当做匿名请求。 +匿名请求的用户名为 system:anonymous， +用户组名为 system:unauthenticated。 +
--api-audiences strings
+ +API 的标识符。 +服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。 +如果配置了 --service-account-issuer 标志，但未配置此标志， +则此字段默认为包含发布者 URL 的单个元素列表。 +
--apiserver-count int     默认值：1
+ +集群中运行的 API 服务器数量，必须为正数。 +（在启用 --endpoint-reconciler-type=master-count 时使用。） +
--audit-log-batch-buffer-size int     默认值：10000
+ +批处理和写入之前用于存储事件的缓冲区大小。 +仅在批处理模式下使用。 +
--audit-log-batch-max-size int     默认值：1
+ +每个批次的最大大小。仅在批处理模式下使用。 +
--audit-log-batch-max-wait duration
+ +强制写入尚未达到最大大小的批次之前要等待的时间。 +仅在批处理模式下使用。 +
--audit-log-batch-throttle-burst int
+ +如果之前未使用 ThrottleQPS，则为同时发送的最大请求数。 +仅在批处理模式下使用。 +
--audit-log-batch-throttle-enable
+ +是否启用了批量限制。仅在批处理模式下使用。 +
--audit-log-batch-throttle-qps float
+ +每秒的最大平均批次数。仅在批处理模式下使用。 +
--audit-log-compress
+ +若设置了此标志，则被轮换的日志文件会使用 gzip 压缩。 +
--audit-log-format string     默认值："json"
+ +所保存的审计格式。 +"legacy" 表示每行一个事件的文本格式。"json" 表示结构化的 JSON 格式。 +已知格式为 legacy，json。 +
--audit-log-maxage int
+ +根据文件名中编码的时间戳保留旧审计日志文件的最大天数。 +
--audit-log-maxbackup int
+ +要保留的旧的审计日志文件个数上限。 +
--audit-log-maxsize int
+ +轮换之前，审计日志文件的最大大小（以兆字节为单位）。 +
--audit-log-mode string     默认值："blocking"
+ +用来发送审计事件的策略。 +阻塞（blocking）表示发送事件应阻止服务器响应。 +批处理（batch）会导致后端异步缓冲和写入事件。 +已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 +
--audit-log-path string
+ +如果设置，则所有到达 API 服务器的请求都将记录到该文件中。 +"-" 表示标准输出。 +
--audit-log-truncate-enabled
+ +是否启用事件和批次截断。 +
--audit-log-truncate-max-batch-size int     默认值：10485760
+ +发送到下层后端的每批次的最大数据量。 +实际的序列化大小可能会增加数百个字节。 +如果一个批次超出此限制，则将其分成几个较小的批次。 +
--audit-log-truncate-max-event-size int     默认值：102400
+ +发送到下层后端的每批次的最大数据量。 +如果事件的大小大于此数字，则将删除第一个请求和响应； +如果这样做没有减小足够大的程度，则将丢弃事件。 +
--audit-log-version string     默认值："audit.k8s.io/v1"
+ +用于对写入日志的审计事件执行序列化的 API 组和版本。 +
--audit-policy-file string
+ +定义审计策略配置的文件的路径。 +
--audit-webhook-batch-buffer-size int     默认值：10000
+ +划分批次和写入之前用于存储事件的缓冲区大小。 +仅在批处理模式下使用。 +
--audit-webhook-batch-max-size int     默认值：400
+ +批次的最大大小。 +仅在批处理模式下使用。 +
--audit-webhook-batch-max-wait duration     默认值：30s
+ +强制写入尚未达到最大大小的批处理之前要等待的时间。 +仅在批处理模式下使用。 +
--audit-webhook-batch-throttle-burst int     默认值：15
+ +如果之前未使用 ThrottleQPS，同时发送的最大请求数。 +仅在批处理模式下使用。 +
--audit-webhook-batch-throttle-enable     默认值：true
+ +是否启用了批量限制。仅在批处理模式下使用。 +
--audit-webhook-batch-throttle-qps float32     默认值：10
+ +每秒的最大平均批次数。仅在批处理模式下使用。 +
--audit-webhook-config-file string
+ +定义审计 webhook 配置的 kubeconfig 格式文件的路径。 +
--audit-webhook-initial-backoff duration     默认值：10s
+ +重试第一个失败的请求之前要等待的时间。 +
--audit-webhook-mode string     默认值："batch"
+ +发送审计事件的策略。 +阻止（Blocking）表示发送事件应阻止服务器响应。 +批处理（Batch）导致后端异步缓冲和写入事件。 +已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 +
--audit-webhook-truncate-enabled
+ +是否启用事件和批处理截断。 +
--audit-webhook-truncate-max-batch-size int     默认值：10485760
+ +发送到下层后端的批次的最大数据量。 +实际的序列化大小可能会增加数百个字节。 +如果一个批次超出此限制，则将其分成几个较小的批次。 +
--audit-webhook-truncate-max-event-size int     默认值：102400
+ +发送到下层后端的批次的最大数据量。 +如果事件的大小大于此数字，则将删除第一个请求和响应； +如果事件和事件的大小没有减小到一定幅度，则将丢弃事件。 +
--audit-webhook-version string     默认值："audit.k8s.io/v1" +
+ +用于序列化写入 Webhook 的审计事件的 API 组和版本。 +
--authentication-token-webhook-cache-ttl duration     2m0s
+ +对来自 Webhook 令牌身份验证器的响应的缓存时间。 +
--authentication-token-webhook-config-file string
+ +包含 Webhook 配置的 kubeconfig 格式文件，用于进行令牌认证。 +API 服务器将查询远程服务，以对持有者令牌进行身份验证。 +
--authentication-token-webhook-version string     默认值："v1beta1" +
+ +与 Webhook 之间交换 authentication.k8s.io TokenReview 时使用的 API 版本。 +
--authorization-mode stringSlice     默认值："AlwaysAllow"
+ +在安全端口上进行鉴权的插件的顺序列表。 +逗号分隔的列表：AlwaysAllow、AlwaysDeny、ABAC、Webhook、RBAC、Node。 +
--authorization-policy-file string
+ +包含鉴权策略的文件，其内容为分行 JSON 格式， +在安全端口上与 --authorization-mode=ABAC 一起使用。 +
--authorization-webhook-cache-authorized-ttl duration     默认值：5m0s
+ +对来自 Webhook 鉴权组件的 “授权（authorized）” 响应的缓存时间。 +
--authorization-webhook-cache-unauthorized-ttl duration     默认值：30s
+ +对来自 Webhook 鉴权模块的 “未授权（unauthorized）” 响应的缓存时间。 +
--authorization-webhook-config-file string
+ +包含 Webhook 配置的文件，其格式为 kubeconfig， +与 --authorization-mode=Webhook 一起使用。 +API 服务器将查询远程服务，以对 API 服务器的安全端口的访问执行鉴权。 +
--authorization-webhook-version string     默认值："v1beta1"
+ +与 Webhook 之间交换 authorization.k8s.io SubjectAccessReview 时使用的 API 版本。 +
--azure-container-registry-config string
+ +包含 Azure 容器仓库配置信息的文件的路径。 +
--bind-address string     默认值："0.0.0.0"
+ +用来监听 --secure-port 端口的 IP 地址。 +集群的其余部分以及 CLI/web 客户端必须可以访问所关联的接口。 +如果为空白或未指定地址（0.0.0.0 或 ::），则将使用所有接口。 +
--cert-dir string     默认值："/var/run/kubernetes"
+ +TLS 证书所在的目录。 +如果提供了 --tls-cert-file 和 --tls-private-key-file +标志值，则将忽略此标志。 +
--client-ca-file string
+ +如果已设置，则使用与客户端证书的 CommonName 对应的标识对任何出示由 +client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。 +
--cloud-config string
+ +云厂商配置文件的路径。空字符串表示无配置文件。 +
--cloud-provider string
+ +云服务提供商。空字符串表示没有云厂商。 +
--cloud-provider-gce-l7lb-src-cidrs cidrs     默认值："130.211.0.0/22,35.191.0.0/16"
+ +在 GCE 防火墙中打开 CIDR，以进行第 7 层负载均衡流量代理和健康状况检查。 +
--contention-profiling
+ +如果启用了性能分析，则启用锁争用性能分析。 +
--cors-allowed-origins strings
+ +CORS 允许的来源清单，以逗号分隔。 +允许的来源可以是支持子域匹配的正则表达式。 +如果此列表为空，则不会启用 CORS。 +
--default-not-ready-toleration-seconds int     默认值：300
+ +对污点 NotReady:NoExecute 的容忍时长（以秒计）。 +默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 +
--default-unreachable-toleration-seconds int     默认值：300
+ +对污点 Unreachable:NoExecute 的容忍时长（以秒计） +默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 +
--default-watch-cache-size int     默认值：100
+ +默认监听（watch）缓存大小。 +如果为零，则将为没有设置默认监视大小的资源禁用监视缓存。 +
--delete-collection-workers int     默认值： 1
+ +为 DeleteCollection 调用而产生的工作线程数。 +这些用于加速名字空间清理。 +
--disable-admission-plugins strings
+ +尽管位于默认启用的插件列表中（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）仍须被禁用的插件。 +
取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook。 +
该标志中插件的顺序无关紧要。 +
--disabled-metrics strings
+ +此标志为行为不正确的度量指标提供一种处理方案。 +你必须提供完全限定的指标名称才能将其禁止。 +声明：禁用度量值的行为优先于显示已隐藏的度量值。 +
--egress-selector-config-file string
+ +带有 API 服务器出站选择器配置的文件。 +
--enable-admission-plugins stringSlice
+ +除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的插件 +
取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook +
该标志中插件的顺序无关紧要。 +
--enable-aggregator-routing
+ +允许聚合器将请求路由到端点 IP 而非集群 IP。 +
--enable-bootstrap-token-auth
+ +启用以允许将 "kube-system" 名字空间中类型为 "bootstrap.kubernetes.io/token" +的 Secret 用于 TLS 引导身份验证。 +
--enable-garbage-collector     默认值：true
+ +启用通用垃圾收集器。必须与 kube-controller-manager 的相应标志同步。 +
--enable-priority-and-fairness     默认值：true
+ +如果为 true 且启用了 APIPriorityAndFairness 特性门控， +请使用增强的处理程序替换 max-in-flight 处理程序， +以便根据优先级和公平性完成排队和调度。 +
--encryption-provider-config string
+ +包含加密提供程序配置信息的文件，用在 etcd 中所存储的 Secret 上。 +
--endpoint-reconciler-type string     默认值："lease"
+ +使用端点协调器（master-count、lease 或 none）。 +
--etcd-cafile string
+ +用于保护 etcd 通信的 SSL 证书颁发机构文件。 +
--etcd-certfile string
+ +用于保护 etcd 通信的 SSL 证书文件。 +
--etcd-compaction-interval duration     默认值：5m0s
+ +压缩请求的间隔。 +如果为0，则禁用来自 API 服务器的压缩请求。 +
--etcd-count-metric-poll-period duration     默认值：1m0s
+ +针对每种类型的资源数量轮询 etcd 的频率。 +0 值表示禁用度量值收集。 +
--etcd-db-metric-poll-interval duration     默认值：30s
+ +轮询 etcd 和更新度量值的请求间隔。0 值表示禁用度量值收集。 +
--etcd-healthcheck-timeout duration      +检查 etcd 健康状况时使用的超时时长。 +
--etcd-keyfile string
+ +用于保护 etcd 通信的 SSL 密钥文件。 +
--etcd-prefix string     默认值："/registry"
+ +要在 etcd 中所有资源路径之前添加的前缀。 +
--etcd-servers strings
+ +要连接的 etcd 服务器列表（scheme://ip:port），以逗号分隔。 +
--etcd-servers-overrides strings
+ +etcd 服务器针对每个资源的重载设置，以逗号分隔。 +单个替代格式：组/资源#服务器（group/resource#servers）， +其中服务器是 URL，以分号分隔。 +
--event-ttl duration     默认值：1h0m0s
+ +事件的保留时长。 +
--experimental-logging-sanitization
+ +[试验性功能] 启用此标志时，被标记为敏感的字段（密码、密钥、令牌）都不会被日志输出。
+运行时的日志清理可能会引入相当程度的计算开销，因此不应该在产品环境中启用。 +
--external-hostname string
+ +为此主机生成外部化 UR L时要使用的主机名（例如 Swagger API 文档或 OpenID 发现）。 +
--feature-gates <逗号分隔的 'key=True|False' 键值对>
+ +

一组 key=value 对，用来描述测试性/试验性功能的特性门控。可选项有： +APIListChunking=true|false (BETA - 默认值=true)
+APIPriorityAndFairness=true|false (BETA - 默认值=true)
+APIResponseCompression=true|false (BETA - 默认值=true)
+APIServerIdentity=true|false (ALPHA - 默认值=false)
+AllAlpha=true|false (ALPHA - 默认值=false)
+AllBeta=true|false (BETA - 默认值=false)
+AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
+AppArmor=true|false (BETA - 默认值=true)
+BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
+BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
+CPUManager=true|false (BETA - 默认值=true)
+CSIInlineVolume=true|false (BETA - 默认值=true)
+CSIMigration=true|false (BETA - 默认值=true)
+CSIMigrationAWS=true|false (BETA - 默认值=false)
+CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
+CSIMigrationAzureFile=true|false (BETA - 默认值=false)
+CSIMigrationGCE=true|false (BETA - 默认值=false)
+CSIMigrationOpenStack=true|false (BETA - 默认值=true)
+CSIMigrationvSphere=true|false (BETA - 默认值=false)
+CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
+CSIServiceAccountToken=true|false (BETA - 默认值=true)
+CSIStorageCapacity=true|false (BETA - 默认值=true)
+CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
+CSIVolumeHealth=true|false (ALPHA - 默认值=false)
+ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
+ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
+CronJobControllerV2=true|false (BETA - 默认值=true)
+CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
+DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
+DefaultPodTopologySpread=true|false (BETA - 默认值=true)
+DevicePlugins=true|false (BETA - 默认值=true)
+DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
+DownwardAPIHugePages=true|false (BETA - 默认值=false)
+DynamicKubeletConfig=true|false (BETA - 默认值=true)
+EfficientWatchResumption=true|false (BETA - 默认值=true)
+EndpointSliceProxying=true|false (BETA - 默认值=true)
+EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
+EphemeralContainers=true|false (ALPHA - 默认值=false)
+ExpandCSIVolumes=true|false (BETA - 默认值=true)
+ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
+ExpandPersistentVolumes=true|false (BETA - 默认值=true)
+ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
+GenericEphemeralVolume=true|false (BETA - 默认值=true)
+GracefulNodeShutdown=true|false (BETA - 默认值=true)
+HPAContainerMetrics=true|false (ALPHA - 默认值=false)
+HPAScaleToZero=true|false (ALPHA - 默认值=false)
+HugePageStorageMediumSize=true|false (BETA - 默认值=true)
+IPv6DualStack=true|false (BETA - 默认值=true)
+InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
+IndexedJob=true|false (ALPHA - 默认值=false)
+IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
+KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
+KubeletPodResources=true|false (BETA - 默认值=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
+LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
+LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
+LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
+MemoryManager=true|false (ALPHA - 默认值=false)
+MixedProtocolLBService=true|false (ALPHA - 默认值=false)
+NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
+NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
+NonPreemptingPriority=true|false (BETA - 默认值=true)
+PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
+PodDeletionCost=true|false (ALPHA - 默认值=false)
+PodOverhead=true|false (BETA - 默认值=true)
+PreferNominatedNode=true|false (ALPHA - 默认值=false)
+ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
+ProcMountType=true|false (ALPHA - 默认值=false)
+QOSReserved=true|false (ALPHA - 默认值=false)
+RemainingItemCount=true|false (BETA - 默认值=true)
+RemoveSelfLink=true|false (BETA - 默认值=true)
+RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
+ServerSideApply=true|false (BETA - 默认值=true)
+ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
+ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
+ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
+ServiceTopology=true|false (ALPHA - 默认值=false)
+SetHostnameAsFQDN=true|false (BETA - 默认值=true)
+SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
+StorageVersionAPI=true|false (ALPHA - 默认值=false)
+StorageVersionHash=true|false (BETA - 默认值=true)
+SuspendJob=true|false (ALPHA - 默认值=false)
+TTLAfterFinished=true|false (BETA - 默认值=true)
+TopologyAwareHints=true|false (ALPHA - 默认值=false)
+TopologyManager=true|false (BETA - 默认值=true)
+ValidateProxyRedirects=true|false (BETA - 默认值=true)
+VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
+WarningHeaders=true|false (BETA - 默认值=true)
+WinDSR=true|false (ALPHA - 默认值=false)
+WinOverlay=true|false (BETA - 默认值=true)
+WindowsEndpointSliceProxying=true|false (BETA - 默认值=true)

+
--goaway-chance float
+ +为防止 HTTP/2 客户端卡在单个 API 服务器上，可启用随机关闭连接（GOAWAY）。 +客户端的其他运行中请求将不会受到影响，并且客户端将重新连接， +可能会在再次通过负载平衡器后登陆到其他 API 服务器上。 +此参数设置将发送 GOAWAY 的请求的比例。 +具有单个 API 服务器或不使用负载平衡器的群集不应启用此功能。 +最小值为0（关闭），最大值为 .02（1/50 请求）； 建议使用 .001（1/1000）。 +
-h, --help
+ +kube-apiserver 的帮助命令 +
--http2-max-streams-per-connection int
+ +服务器为客户端提供的 HTTP/2 连接中最大流数的限制。 +零表示使用 GoLang 的默认值。 +
--identity-lease-duration-seconds int     默认值：3600
+ +kube-apiserver 租约时长（按秒计），必须是正数。 +（当 APIServerIdentity 特性门控被启用时使用此标志值） +
--identity-lease-renew-interval-seconds int     默认值：10
+ +kube-apiserver 对其租约进行续期的时间间隔（按秒计），必须是正数。 +（当 APIServerIdentity 特性门控被启用时使用此标志值） +
--kubelet-certificate-authority string
+ +证书颁发机构的证书文件的路径。 +
--kubelet-client-certificate string
+ +TLS 的客户端证书文件的路径。 +
--kubelet-client-key string
+ +TLS 客户端密钥文件的路径。 +
--kubelet-preferred-address-types strings     默认值：Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP
+ +用于 kubelet 连接的首选 NodeAddressTypes 列表。 +
--kubelet-timeout duration     默认值：5s
+ +kubelet 操作超时时间。 +
--kubernetes-service-node-port int
+ +如果非零，那么 Kubernetes 主服务（由 apiserver 创建/维护）将是 NodePort 类型， +使用它作为端口的值。 +如果为零，则 Kubernetes 主服务将为 ClusterIP 类型。 +
--lease-reuse-duration-seconds int     默认值：60
+ +每个租约被重用的时长。 +如果此值比较低，可以避免大量对象重用此租约。 +注意，如果此值过小，可能导致存储层出现性能问题。 +
--livez-grace-period duration
+ +此选项代表 API 服务器完成启动序列并生效所需的最长时间。 +从 API 服务器的启动时间到这段时间为止， +/livez 将假定未完成的启动后钩子将成功完成，因此返回 true。 +
--log-backtrace-at traceLocation     默认值：:0
+ +当日志机制执行到'文件 :N'时，生成堆栈跟踪。 +
--log-dir string
+ +如果为非空，则在此目录中写入日志文件。 +
--log-file string
+ +如果为非空，使用此值作为日志文件。 +
--log-file-max-size uint     默认值：1800
+ +定义日志文件可以增长到的最大大小。单位为兆字节。 +如果值为 0，则最大文件大小为无限制。 +
--log-flush-frequency duration     默认值：5s
+ +两次日志刷新之间的最大秒数 +
--logging-format string     默认值："text"
+ +设置日志格式。允许的格式："json"，"json"。
+非默认格式不支持以下标志：--add-dir-header、--alsologtostderr、--log-backtrace-at、--log-dir、--log-file、--log-file-max-size、--logtostderr、--one-output、-skip-headers、-skip-log-headers、--stderrthreshold、-vmodule 和 --log-flush-frequency。
+当前非默认选择为 alpha，会随时更改而不会发出警告。 +
--logtostderr     默认值：true
+ +在标准错误而不是文件中输出日志记录。 +
--master-service-namespace string     默认值："default"
+ +已废弃：应该从其中将 Kubernetes 主服务注入到 Pod 中的名字空间。 +
--max-connection-bytes-per-sec int
+ +如果不为零，则将每个用户连接限制为该数（字节数/秒）。 +当前仅适用于长时间运行的请求。 +
--max-mutating-requests-inflight int     默认值：200
+ +在给定时间内进行中变更类型请求的最大个数。 +当超过该值时，服务将拒绝所有请求。 +零表示无限制。 +
--max-requests-inflight int     默认值：400
+ +在给定时间内进行中非变更类型请求的最大数量。 +当超过该值时，服务将拒绝所有请求。 +零表示无限制。 +
--min-request-timeout int     默认值：1800
+ +可选字段，表示处理程序在请求超时前，必须保持其处于打开状态的最小秒数。 +当前只对监听（Watch）请求的处理程序有效，它基于这个值选择一个随机数作为连接超时值， +以达到分散负载的目的。 +
--oidc-ca-file string
+ +如果设置该值，将会使用 oidc-ca-file 中的机构之一对 OpenID 服务的证书进行验证， +否则将会使用主机的根 CA 对其进行验证。 +
--oidc-client-id string
+ +OpenID 连接客户端的要使用的客户 ID，如果设置了 oidc-issuer-url，则必须设置这个值。 +
--oidc-groups-claim string
+ +如果提供该值，这个自定义 OpenID 连接声明将被用来设定用户组。 +该声明值需要是一个字符串或字符串数组。 +此标志为实验性的，请查阅身份认证相关文档进一步了解详细信息。 +
--oidc-groups-prefix string
+ +如果提供了此值，则所有组都将以该值作为前缀，以防止与其他身份认证策略冲突。 +
--oidc-issuer-url string
+ +OpenID 颁发者 URL，只接受 HTTPS 方案。 +如果设置该值，它将被用于验证 OIDC JSON Web Token(JWT)。 +
--oidc-required-claim <逗号分隔的 'key=value' 键值对列表>
+ +描述 ID 令牌中必需声明的键值对。 +如果设置此值，则会验证 ID 令牌中存在与该声明匹配的值。 +重复此标志以指定多个声明。 +
--oidc-signing-algs strings     默认值：RS256
+ +允许的 JOSE 非对称签名算法的逗号分隔列表。 +若 JWT 所带的 "alg" 标头值不在列表中，则该 JWT 将被拒绝。 +取值依据 RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1 定义。 +
--oidc-username-claim string     默认值："sub"
+ +要用作用户名的 OpenID 声明。 +请注意，除默认声明（"sub"）以外的其他声明不能保证是唯一且不可变的。 +此标志是实验性的，请参阅身份认证文档以获取更多详细信息。 +
--oidc-username-prefix string
+ +如果提供，则所有用户名都将以该值作为前缀。 +如果未提供，则除 "email" 之外的用户名声明都会添加颁发者 URL 作为前缀，以避免冲突。 +要略过添加前缀处理，请设置值为 "-"。 +
--one-output
+ +此标志为真时，日志只会被写入到其原生的严重性级别中（而不是同时写到所有较低 +严重性级别中）。 +
--permit-address-sharing     默认值：false

+ +若此标志为 true，则使用 SO_REUSEADDR 来绑定端口。 +这样设置可以同时绑定到用通配符表示的类似 0.0.0.0 这种 IP 地址， +以及特定的 IP 地址。也可以避免等待内核释放 TIME_WAIT 状态的套接字。 +

--permit-port-sharing     默认值：false
+ +如果为 true，则在绑定端口时将使用 SO_REUSEPORT， +这样多个实例可以绑定到同一地址和端口上。 +
--profiling     默认值：true
+ +通过 Web 接口 host:port/debug/pprof/ 启用性能分析。 +
--proxy-client-cert-file string
+ +当必须调用外部程序以处理请求时，用于证明聚合器或者 kube-apiserver 的身份的客户端证书。 +包括代理转发到用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 +Kubernetes 期望此证书包含来自于 --requestheader-client-ca-file 标志中所给 CA 的签名。 +该 CA 在 kube-system 命名空间的 "extension-apiserver-authentication" ConfigMap 中公开。 +从 kube-aggregator 收到调用的组件应该使用该 CA 进行各自的双向 TLS 验证。 +
--proxy-client-key-file string
+ +当必须调用外部程序来处理请求时，用来证明聚合器或者 kube-apiserver 的身份的客户端私钥。 +这包括代理转发给用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 +
--request-timeout duration     默认值：1m0s
+ +可选字段，指示处理程序在超时之前必须保持打开请求的持续时间。 +这是请求的默认请求超时，但对于特定类型的请求，可能会被 +--min-request-timeout等标志覆盖。 +
--requestheader-allowed-names strings
+ +此值为客户端证书通用名称（Common Name）的列表；表中所列的表项可以用来提供用户名， +方式是使用 --requestheader-username-headers 所指定的头部。 +如果为空，能够通过 --requestheader-client-ca-file 中机构 +认证的客户端证书都是被允许的。 +
--requestheader-client-ca-file string
+ +在信任请求头中以 --requestheader-username-headers 指示的用户名之前， +用于验证接入请求中客户端证书的根证书包。 +警告：一般不要假定传入请求已被授权。 +
--requestheader-extra-headers-prefix strings
+ +用于查验请求头部的前缀列表。建议使用 X-Remote-Extra-。 +
--requestheader-group-headers strings
+ +用于查验用户组的请求头部列表。建议使用 X-Remote-Group。 +
--requestheader-username-headers strings
+ +用于查验用户名的请求头头列表。建议使用 X-Remote-User。 +
--runtime-config <逗号分隔的 'key=value' 对列表>
+ +一组启用或禁用内置 API 的键值对。支持的选项包括： +
v1=true|false（针对核心 API 组） +
<group>/<version>=true|false（针对特定 API 组和版本，例如：apps/v1=true） +
api/all=true|false 控制所有 API 版本 +
api/ga=true|false 控制所有 v[0-9]+ API 版本 +
api/beta=true|false 控制所有 v[0-9]+beta[0-9]+ API 版本 +
api/alpha=true|false 控制所有 v[0-9]+alpha[0-9]+ API 版本 +
api/legacy 已弃用，并将在以后的版本中删除 +
--secure-port int     默认值：6443
+ +带身份验证和鉴权机制的 HTTPS 服务端口。 +不能用 0 关闭。 +
--service-account-extend-token-expiration     默认值：true
+ +在生成令牌时，启用投射服务帐户到期时间扩展， +这有助于从旧版令牌安全地过渡到绑定的服务帐户令牌功能。 +如果启用此标志，则准入插件注入的令牌的过期时间将延长至 1 年，以防止过渡期间发生意外故障， +并忽略 service-account-max-token-expiration 的值。 +
--service-account-issuer string
+ +服务帐号令牌颁发者的标识符。 +颁发者将在已办法令牌的 "iss" 声明中检查此标识符。 +此值为字符串或 URI。 +如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI，则即使特性门控设置为 true， +ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 +强烈建议该值符合 OpenID 规范：https://openid.net/specs/openid-connect-discovery-1_0.html。 +实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 +还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration +处提供 OpenID 发现文档。 +
--service-account-jwks-uri string
+ +覆盖 /.well-known/openid-configuration 提供的发现文档中 JSON Web 密钥集的 URI。 +如果发现文档和密钥集是通过 API 服务器外部 +（而非自动检测到或被外部主机名覆盖）之外的 URL 提供给依赖方的，则此标志很有用。 +仅在启用 ServiceAccountIssuerDiscovery 特性门控的情况下有效。 +
--service-account-key-file strings
+ +包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。 +指定的文件可以包含多个键，并且可以使用不同的文件多次指定标志。 +如果未指定，则使用 --tls-private-key-file。 +提供 --service-account-signing-key 时必须指定。 +
--service-account-lookup     默认值：true
+ +如果为 true，则在身份认证时验证 etcd 中是否存在 ServiceAccount 令牌。 +
--service-account-max-token-expiration duration
+ +服务帐户令牌发布者创建的令牌的最长有效期。 +如果请求有效期大于此值的有效令牌请求，将使用此值的有效期颁发令牌。 +
--service-account-signing-key-file string
+ +包含服务帐户令牌颁发者当前私钥的文件的路径。 +颁发者将使用此私钥签署所颁发的 ID 令牌。 +
--service-cluster-ip-range string
+ +CIDR 表示的 IP 范围用来为服务分配集群 IP。 +此地址不得与指定给节点或 Pod 的任何 IP 范围重叠。 +
--service-node-port-range <形式为 'N1-N2' 的字符串>     默认值：30000-32767
+ +保留给具有 NodePort 可见性的服务的端口范围。 +例如："30000-32767"。范围的两端都包括在内。 +
--show-hidden-metrics-for-version string
+ +你要显示隐藏指标的先前版本。仅先前的次要版本有意义，不允许其他值。 +格式为 <major>.<minor>，例如："1.16"。 +这种格式的目的是确保你有机会注意到下一个版本是否隐藏了其他指标， +而不是在此之后将它们从发行版中永久删除时感到惊讶。 +
--shutdown-delay-duration duration
+ +延迟终止时间。在此期间，服务器将继续正常处理请求。 +端点 /healthz 和 /livez 将返回成功，但是 /readyz 立即返回失败。 +在此延迟过去之后，将开始正常终止。 +这可用于允许负载平衡器停止向该服务器发送流量。 +
--skip-headers
+ +如果为 true，日志消息中避免标题前缀。 +
--skip-log-headers
+ +如果为 true，则在打开日志文件时避免标题。 +
--stderrthreshold int     默认值：2
+ +将达到或超过此阈值的日志写到标准错误输出 +
--storage-backend string
+ +持久化存储后端。选项："etcd3"（默认）。 +
--storage-media-type string     默认值："application/vnd.kubernetes.protobuf"
+ +用于在存储中存储对象的媒体类型。 +某些资源或存储后端可能仅支持特定的媒体类型，并且将忽略此设置。 +
--strict-transport-security-directives strings

+ +为 HSTS 所设置的指令列表，用逗号分隔。 +如果此列表为空，则不会添加 HSTS 指令。 +例如： 'max-age=31536000,includeSubDomains,preload' +

--tls-cert-file string
+ +包含用于 HTTPS 的默认 x509 证书的文件。（CA 证书（如果有）在服务器证书之后并置）。 +如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 +--tls-private-key-file， +为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 +
--tls-cipher-suites strings
+ +服务器的密码套件的列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 +
首选值： +TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、 TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384. +不安全的值有： +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA。 +
--tls-min-version string
+ +支持的最低 TLS 版本。可能的值：VersionTLS10，VersionTLS11，VersionTLS12，VersionTLS13 +
--tls-private-key-file string
+ +包含匹配 --tls-cert-file 的 x509 证书私钥的文件。 +
--tls-sni-cert-key string     默认值： []
+ +一对 x509 证书和私钥文件路径，（可选）后缀为全限定域名的域名模式列表，可以使用带有通配符的前缀。 +域模式也允许使用 IP 地址，但仅当 apiserver 对客户端请求的IP地址具有可见性时，才应使用 IP。 +如果未提供域模式，则提取证书的名称。 +非通配符匹配优先于通配符匹配，显式域模式优先于提取出的名称。 +对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。 +示例："example.crt,example.key" 或 "foo.crt,foo.key:\*.foo.com,foo.com"。 +
--token-auth-file string
+ +如果设置该值，这个文件将被用于通过令牌认证来保护 API 服务的安全端口。 +
-v, --v int
+ +日志级别详细程度的数字。 +
--version version[=true]
+ +打印版本信息并退出 +
--vmodule <用逗号分隔的多个 'pattern=N' 配置字符串>
+ +以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录。 +
--watch-cache     默认值：true
+ +在 API 服务器中启用监视缓存。 +
--watch-cache-sizes strings
+ +某些资源（Pods、Nodes 等）的监视缓存大小设置，以逗号分隔。 +每个资源对应的设置格式：resource[.group]#size，其中 +resource 为小写复数（无版本）， +对于 apiVersion v1（旧版核心 API）的资源要省略 group， +对其它资源要给出 group；size 为一个数字。 +启用 watch-cache 时，此功能生效。 +某些资源（replicationcontrollers、endpoints、 +nodes、pods、services、 +apiservices.apiregistration.k8s.io） +具有通过启发式设置的系统默认值，其他资源默认为 +default-watch-cache-size。 +
+ diff --git a/content/ja/docs/reference/config-api/apiserver-audit.v1.md b/content/ja/docs/reference/config-api/apiserver-audit.v1.md new file mode 100644 index 0000000000..11df06bd8c --- /dev/null +++ b/content/ja/docs/reference/config-api/apiserver-audit.v1.md @@ -0,0 +1,620 @@ +--- +title: kube-apiserver Audit Configuration (v1) +content_type: tool-reference +package: audit.k8s.io/v1 +auto_generated: true +--- + + +## Resource Types + + +- [Event](#audit-k8s-io-v1-Event) +- [EventList](#audit-k8s-io-v1-EventList) +- [Policy](#audit-k8s-io-v1-Policy) +- [PolicyList](#audit-k8s-io-v1-PolicyList) + + + + +## `Event` {#audit-k8s-io-v1-Event} + + + + +**Appears in:** + +- [EventList](#audit-k8s-io-v1-EventList) + + +Event captures all the information that can be included in an API audit log. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		audit.k8s.io/v1
kind
string		Event
level [Required]
+Level +		 + AuditLevel at which event was generated
auditID [Required]
+k8s.io/apimachinery/pkg/types.UID +		 + Unique audit ID, generated for each request.
stage [Required]
+Stage +		 + Stage of the request handling when this event instance was generated.
requestURI [Required]
+string +		 + RequestURI is the request URI as sent by the client to a server.
verb [Required]
+string +		 + Verb is the kubernetes verb associated with the request. +For non-resource requests, this is the lower-cased HTTP method.
user [Required]
+authentication/v1.UserInfo +		 + Authenticated user information.
impersonatedUser
+authentication/v1.UserInfo +		 + Impersonated user information.
sourceIPs
+[]string +		 + Source IPs, from where the request originated and intermediate proxies.
userAgent
+string +		 + UserAgent records the user agent string reported by the client. +Note that the UserAgent is provided by the client, and must not be trusted.
objectRef
+ObjectReference +		 + Object reference this request is targeted at. +Does not apply for List-type requests, or non-resource requests.
responseStatus
+meta/v1.Status +		 + The response status, populated even when the ResponseObject is not a Status type. +For successful responses, this will only include the Code and StatusSuccess. +For non-status type error responses, this will be auto-populated with the error Message.
requestObject
+k8s.io/apimachinery/pkg/runtime.Unknown +		 + API object from the request, in JSON format. The RequestObject is recorded as-is in the request +(possibly re-encoded as JSON), prior to version conversion, defaulting, admission or +merging. It is an external versioned object type, and may not be a valid object on its own. +Omitted for non-resource requests. Only logged at Request Level and higher.
responseObject
+k8s.io/apimachinery/pkg/runtime.Unknown +		 + API object returned in the response, in JSON. The ResponseObject is recorded after conversion +to the external type, and serialized as JSON. Omitted for non-resource requests. Only logged +at Response Level.
requestReceivedTimestamp
+meta/v1.MicroTime +		 + Time the request reached the apiserver.
stageTimestamp
+meta/v1.MicroTime +		 + Time the request reached current audit stage.
annotations
+map[string]string +		 + Annotations is an unstructured key value map stored with an audit event that may be set by +plugins invoked in the request serving chain, including authentication, authorization and +admission plugins. Note that these annotations are for the audit event, and do not correspond +to the metadata.annotations of the submitted object. Keys should uniquely identify the informing +component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values +should be short. Annotations are included in the Metadata level.
+ + + +## `EventList` {#audit-k8s-io-v1-EventList} + + + + + +EventList is a list of audit Events. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		audit.k8s.io/v1
kind
string		EventList
metadata
+meta/v1.ListMeta +		 + No description provided. +
items [Required]
+[]Event +		 + No description provided. +
+ + + +## `Policy` {#audit-k8s-io-v1-Policy} + + + + +**Appears in:** + +- [PolicyList](#audit-k8s-io-v1-PolicyList) + + +Policy defines the configuration of audit logging, and the rules for how different request +categories are logged. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		audit.k8s.io/v1
kind
string		Policy
metadata
+meta/v1.ObjectMeta +		 + ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field.
rules [Required]
+[]PolicyRule +		 + Rules specify the audit Level a request should be recorded at. +A request may match multiple rules, in which case the FIRST matching rule is used. +The default audit level is None, but can be overridden by a catch-all rule at the end of the list. +PolicyRules are strictly ordered.
omitStages
+[]Stage +		 + OmitStages is a list of stages for which no events are created. Note that this can also +be specified per rule in which case the union of both are omitted.
+ + + +## `PolicyList` {#audit-k8s-io-v1-PolicyList} + + + + + +PolicyList is a list of audit Policies. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		audit.k8s.io/v1
kind
string		PolicyList
metadata
+meta/v1.ListMeta +		 + No description provided. +
items [Required]
+[]Policy +		 + No description provided. +
+ + + +## `GroupResources` {#audit-k8s-io-v1-GroupResources} + + + + +**Appears in:** + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +GroupResources represents resource kinds in an API group. + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
group
+string +		 + Group is the name of the API group that contains the resources. +The empty string represents the core API group.
resources
+[]string +		 + Resources is a list of resources this rule applies to. + +For example: +'pods' matches pods. +'pods/log' matches the log subresource of pods. +'∗' matches all resources and their subresources. +'pods/∗' matches all subresources of pods. +'∗/scale' matches all scale subresources. + +If wildcard is present, the validation rule will ensure resources do not +overlap with each other. + +An empty list implies all resources and subresources in this API groups apply.
resourceNames
+[]string +		 + ResourceNames is a list of resource instance names that the policy matches. +Using this field requires Resources to be specified. +An empty list implies that every instance of the resource is matched.
+ + + +## `Level` {#audit-k8s-io-v1-Level} + +(Alias of `string`) + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +Level defines the amount of information logged during auditing + + + + + +## `ObjectReference` {#audit-k8s-io-v1-ObjectReference} + + + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + + +ObjectReference contains enough information to let you inspect or modify the referred object. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
resource
+string +		 + No description provided. +
namespace
+string +		 + No description provided. +
name
+string +		 + No description provided. +
uid
+k8s.io/apimachinery/pkg/types.UID +		 + No description provided. +
apiGroup
+string +		 + APIGroup is the name of the API group that contains the referred object. +The empty string represents the core API group.
apiVersion
+string +		 + APIVersion is the version of the API group that contains the referred object.
resourceVersion
+string +		 + No description provided. +
subresource
+string +		 + No description provided. +
+ + + +## `PolicyRule` {#audit-k8s-io-v1-PolicyRule} + + + + +**Appears in:** + +- [Policy](#audit-k8s-io-v1-Policy) + + +PolicyRule maps requests based off metadata to an audit Level. +Requests must match the rules of every field (an intersection of rules). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
level [Required]
+Level +		 + The Level that requests matching this rule are recorded at.
users
+[]string +		 + The users (by authenticated user name) this rule applies to. +An empty list implies every user.
userGroups
+[]string +		 + The user groups this rule applies to. A user is considered matching +if it is a member of any of the UserGroups. +An empty list implies every user group.
verbs
+[]string +		 + The verbs that match this rule. +An empty list implies every verb.
resources
+[]GroupResources +		 + Resources that this rule matches. An empty list implies all kinds in all API groups.
namespaces
+[]string +		 + Namespaces that this rule matches. +The empty string "" matches non-namespaced resources. +An empty list implies every namespace.
nonResourceURLs
+[]string +		 + NonResourceURLs is a set of URL paths that should be audited. +∗s are allowed, but only as the full, final step in the path. +Examples: + "/metrics" - Log requests for apiserver metrics + "/healthz∗" - Log all health checks
omitStages
+[]Stage +		 + OmitStages is a list of stages for which no events are created. Note that this can also +be specified policy wide in which case the union of both are omitted. +An empty list means no restrictions will apply.
+ + + +## `Stage` {#audit-k8s-io-v1-Stage} + +(Alias of `string`) + + +**Appears in:** + +- [Event](#audit-k8s-io-v1-Event) + +- [Policy](#audit-k8s-io-v1-Policy) + +- [PolicyRule](#audit-k8s-io-v1-PolicyRule) + + +Stage defines the stages in request handling that audit events may be generated. + + + + From 3a7107afb10c237d4ad50cf1c8e49ad695c75c50 Mon Sep 17 00:00:00 2001 From: ptux Date: Sat, 20 Nov 2021 00:22:52 +0900 Subject: [PATCH 005/145] bedtime --- .../tasks/debug-application-cluster/audit.md | 55 ++++++++----------- 1 file changed, 23 insertions(+), 32 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 0cac8fed0e..0b5d68d2c0 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -11,47 +11,38 @@ Kubernetesの監査はクラスタ内の一連の行動を記録するセキュ 監査により、クラスタ管理者は以下の質問に答えることができます: - - what happened? - - when did it happen? - - who initiated it? - - on what did it happen? - - where was it observed? - - from where was it initiated? - - to where was it going? + - 何が起きたのか？ + - いつ起こったのか？ + - 誰がそれを始めたのか？ + - 何のために起こったのか？ + - それはどこで観察されましたか？ + - それはどこから始まったのか？ + - それはどこへ向かっていたのか？ -Audit records begin their lifecycle inside the -[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -component. Each request on each stage -of its execution generates an audit event, which is then pre-processed according to -a certain policy and written to a backend. The policy determines what's recorded -and the backends persist the records. The current backend implementations -include logs files and webhooks. +監査記録は、そのライフサイクルを +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 +各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 +ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 +バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 -Each request can be recorded with an associated _stage_. The defined stages are: +各リクエストは関連する _stage_ で記録されます。 +定義されたステージは以下の通りです: -- `RequestReceived` - The stage for events generated as soon as the audit - handler receives the request, and before it is delegated down the handler - chain. -- `ResponseStarted` - Once the response headers are sent, but before the - response body is sent. This stage is only generated for long-running requests - (e.g. watch). -- `ResponseComplete` - The response body has been completed and no more bytes - will be sent. -- `Panic` - Events generated when a panic occurred. +- `RequestReceived` - 監査ハンドラーがリクエストを受信すると同時に生成されるイベントのステージ。 + つまり、ハンドラーチェーンに委譲される前に生成されるイベントのステージです。 +- `ResponseStarted` - レスポンスヘッダーが送信された後、レスポンスボディが送信される前のステージです。 + このステージは長時間実行されるリクエスト（watchなど）でのみ発生します。 +- `ResponseComplete` - レスポンスボディの送信が完了して、それ以上のバイトは送信されません。 +- `Panic` - パニックが起きたときに発生するイベント。 {{< note >}} -The configuration of an -[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) -is different from the -[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) -API object. +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)API オブジェクトとは異なります。 {{< /note >}} -The audit logging feature increases the memory consumption of the API server -because some context required for auditing is stored for each request. -Memory consumption depends on the audit logging configuration. +監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリ消費量が増加します。 +メモリの消費量は、監査ログ機能の設定によって異なります。 ## Audit policy From 5ac6dd58862d96f8bdb9c4f6bf773cf4b0c38d12 Mon Sep 17 00:00:00 2001 From: ptux Date: Sat, 20 Nov 2021 08:56:04 +0900 Subject: [PATCH 006/145] good morning --- .../tasks/debug-application-cluster/audit.md | 195 +++++++++--------- 1 file changed, 95 insertions(+), 100 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 0b5d68d2c0..fcd9f7e487 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -46,31 +46,36 @@ Kubernetesの監査はクラスタ内の一連の行動を記録するセキュ ## Audit policy -Audit policy defines rules about what events should be recorded and what data -they should include. The audit policy object structure is defined in the -[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy). -When an event is processed, it's -compared against the list of rules in order. The first matching rule sets the -_audit level_ of the event. The defined audit levels are: +監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 +監査ポリシーのオブジェクト構造は、[audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 -- `None` - don't log events that match this rule. -- `Metadata` - log request metadata (requesting user, timestamp, resource, - verb, etc.) but not request or response body. -- `Request` - log event metadata and request body but not response body. - This does not apply for non-resource requests. -- `RequestResponse` - log event metadata, request and response bodies. - This does not apply for non-resource requests. +イベントが処理されると、そのイベントは順番にルールのリストと比較されます。 +最初のマッチングルールは、イベントの監査レベルを設定します。 + +定義されている監査レベルは: + +- `None` - ルールに一致するイベントを記録しません。 +- `Metadata` - lリクエストのメタデータ（リクエストしたユーザー、タイムスタンプ、リソース、動作など）を記録しますが、リクエストやレスポンスのボディは記録しません。 +- `Request` - ログイベントのメタデータとリクエストボディは表示されますが、レスポンスボディは表示されません。 + これは非リソースリクエストには適用されません。 +- `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 + 非リソースリクエストには適用されません。 You can pass a file with the policy to `kube-apiserver` using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal. -Below is an example audit policy file: +`audit-policy-file` フラグを使って、ポリシーを記述したファイルを `kube-apiserver` に渡すことができます。 +このフラグが省略された場合イベントは記録されません。 +監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 +ルールがない(0)ポリシーは不当なものとして扱われます。 + +以下は監査ポリシーファイルの例: {{< codenew file="audit/audit-policy.yaml" >}} -You can use a minimal audit policy file to log all requests at the `Metadata` level: +最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata` レベルで記録することができます。 ```yaml # Log all requests at the Metadata level. @@ -80,28 +85,26 @@ rules: - level: Metadata ``` -If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the -[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) -script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script. +独自の監査プロファイルを作成する場合は、Google Container-Optimized OSの監査プロファイルを出発点として使用できます。 +監査ポリシーファイルを生成する[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)スクリプトを確認することができます。 +スクリプトを直視することで、監査ポリシーファイルのほとんどを見ることができます。 -You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) -for details about the fields defined. +また、定義されているフィールドの詳細については、[Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)を参照できます。 -## Audit backends +## 監査バックエンド -Audit backends persist audit events to an external storage. -Out of the box, the kube-apiserver provides two backends: +監査バックエンドは監査イベントを外部ストレージに永続化します。 +kube-apiserverには2つのバックエンドが用意されています。 -- Log backend, which writes events into the filesystem -- Webhook backend, which sends events to an external HTTP API +- イベントをファイルシステムに書き込むログバックエンド +- 外部のHTTP APIにイベントを送信するWebhookバックエンド + +いずれの場合も、監査イベントはKubernetes API[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)で定義されている構造に従います。 -In all cases, audit events follow a structure defined by the Kubernetes API in the -[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event). {{< note >}} -In case of patches, request body is a JSON array with patch operations, not a JSON object -with an appropriate Kubernetes API object. For example, the following request body is a valid patch -request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`: +パッチの場合、リクエストボディはパッチ操作を含むJSON配列であり、適切なKubernetes APIオブジェクトを含むJSONオブジェクトではありません。 +例えば、以下のリクエストボディは`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`に対する有効なパッチリクエストです。 ```json [ @@ -119,25 +122,25 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`: {{< /note >}} -### Log backend +### ログバックエンド -The log backend writes audit events to a file in [JSONlines](https://jsonlines.org/) format. -You can configure the log audit backend using the following `kube-apiserver` flags: +ログバックエンドは監査イベントを[JSONlines](https://jsonlines.org/)形式のファイルに書き込みます。 +以下の `kube-apiserver` フラグを使ってログ監査バックエンドを設定できます。 -- `--audit-log-path` specifies the log file path that log backend uses to write - audit events. Not specifying this flag disables log backend. `-` means standard out -- `--audit-log-maxage` defined the maximum number of days to retain old audit log files -- `--audit-log-maxbackup` defines the maximum number of audit log files to retain -- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated +- `--audit-log-path` は、ログバックエンドが監査イベントを書き込む際に使用するログファイルのパスを指定します。 + このフラグを指定しないと、ログバックエンドは無効になります。`-` は標準出力を意味します。 +- `--audit-log-maxage` は、古い監査ログファイルを保持する最大日数を定義します。 +- `audit-log-maxbackup`は、保持する監査ログファイルの最大数を定義します。 +- `--audit-log-maxsize` は、監査ログファイルがローテーションされるまでの最大サイズをメガバイト単位で定義します。 -If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath` -to the location of the policy file and log file, so that audit records are persisted. For example: +クラスタのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 +例えば: ```shell --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ --audit-log-path=/var/log/audit.log ``` -then mount the volumes: +それからボリュームをマウントします: ```yaml ... volumeMounts: @@ -148,8 +151,8 @@ volumeMounts: name: audit-log readOnly: false ``` -and finally configure the `hostPath`: +最後に `hostPath` を設定します: ```yaml ... - name: audit @@ -164,81 +167,73 @@ and finally configure the `hostPath`: ``` -### Webhook backend +### Webhook バックエンド -The webhook audit backend sends audit events to a remote web API, which is assumed to -be a form of the Kubernetes API, including means of authentication. You can configure -a webhook audit backend using the following kube-apiserver flags: +Webhook監査バックエンドは、監査イベントをリモートのWeb APIに送信しますが、 +これは認証手段を含むKubernetes APIの形式であると想定されます。 -- `--audit-webhook-config-file` specifies the path to a file with a webhook - configuration. The webhook configuration is effectively a specialized - [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). -- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed - request before retrying. Subsequent requests are retried with exponential backoff. +Webhook監査バックエンドを設定するには、以下のkube-apiserverフラグを使用します。 -The webhook config file uses the kubeconfig format to specify the remote address of -the service and credentials used to connect to it. +- `--audit-webhook-config-file` は、Webhookの設定ファイルのパスを指定します。 + webhookの設定は、事実上特化した [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters) です。 +- `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 + それ以降のリクエストは、指数関数的なバックオフで再試行されます。 -## Event batching {#batching} +Webhookの設定ファイルは、kubeconfig 形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 -Both log and webhook backends support batching. Using webhook as an example, here's the list of -available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag -name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default -throttling is enabled in `webhook` and disabled in `log`. +## イベントバッチ {#batching} -- `--audit-webhook-mode` defines the buffering strategy. One of the following: - - `batch` - buffer events and asynchronously process them in batches. This is the default. - - `blocking` - block API server responses on processing each individual event. - - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at the - RequestReceived stage, the whole request to the kube-apiserver fails. +ログバックエンドとwebhookバックエンドの両方がバッチ処理をサポートしています。 +webhookを例に、利用可能なフラグの一覧を示します。 +ログバックエンドで同じフラグを取得するには、フラグ名の `webhook` を `log` に置き換えてください。 +デフォルトでは、バッチングは `webhook` では有効で、`log` では無効です。 +同様に、デフォルトでは、スロットリングは `webhook` で有効で、`log` では無効です。 -The following flags are used only in the `batch` mode: +- `--audit-webhook-mode` は、バッファリング戦略を定義します。以下のいずれかとなります。 + - `batch` - イベントをバッファリングして、非同期にバッチ処理します。これがデフォルトです。 + - `blocking` - 個々のイベントを処理する際に、APIサーバーの応答をブロックします。 + - `blocking-strict` - blockingと同じですが、RequestReceivedステージでの監査ログに失敗した場合は RequestReceivedステージで監査ログに失敗すると、kube-apiserverへのリクエスト全体が失敗します。 -- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching. - If the rate of incoming events overflows the buffer, events are dropped. -- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch. -- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally - batching events in the queue. -- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated - per second. -- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same - moment if the allowed QPS was underutilized previously. +以下のフラグは `batch` モードでのみ使用されます: -## Parameter tuning +- `--audit-webhook-batch-buffer-size` は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 + 入力イベントの割合がバッファをオーバーフローすると、イベントはドロップされます。 +- `--audit-webhook-batch-max-size` は、1つのバッチに入れるイベントの最大数を定義します。 +- `--audit-webhook-batch-max-wait` は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 +- `--audit-webhook-batch-throttle-qps` は、1秒あたりに生成されるバッチの最大平均数を定義します。 +- `--audit-webhook-batch-throttle-burst` は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 -Parameters should be set to accommodate the load on the API server. -For example, if kube-apiserver receives 100 requests each second, and each request is audited only -on `ResponseStarted` and `ResponseComplete` stages, you should account for ≅200 audit -events being generated each second. Assuming that there are up to 100 events in a batch, -you should set throttling level at least 2 queries per second. Assuming that the backend can take up to -5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events; -that is: 10 batches, or 1000 events. +## パラメータチューニング -In most cases however, the default parameters should be sufficient and you don't have to worry about -setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver -and in the logs to monitor the state of the auditing subsystem. +パラメータは、APIサーバーの負荷に合わせて設定してください。 -- `apiserver_audit_event_total` metric contains the total number of audit events exported. -- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error - during exporting. +例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 +1 つのバッチに最大 100 個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 +バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファサイズを設定する必要があります。 -### Log entry truncation {#truncate} +10バッチ、または1000イベントとなります。 -Both log and webhook backends support limiting the size of events that are logged. -As an example, the following is the list of flags available for the log backend: +しかし、ほとんどの場合デフォルトのパラメーターで十分であり、手動で設定する必要はありません。 +kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 -- `audit-log-truncate-enabled` whether event and batch truncating is enabled. -- `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend. -- `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend. +- `apiserver_audit_event_total` メトリックには、エクスポートされた監査イベントの合計数が含まれます。 +- `apiserver_audit_error_total` メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 -By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set -`audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature. +### ログエントリー・トランケーション {#truncate} + +logバックエンドとwebhookバックエンドは、ログに記録されるイベントのサイズを制限することをサポートしています。 + +例として、logバックエンドで利用可能なフラグの一覧を以下に示します + +- `audit-log-truncate-enabled` イベントとバッチの切り捨てを有効にするかどうかです。 +- `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 +- `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 + +デフォルトでは、`webhook` と `log` の両方で切り捨ては無効になっていますが、クラスタ管理者は `audit-log-truncate-enabled` または `audit-webhook-truncate-enabled` を設定して、この機能を有効にする必要があります。 ## {{% heading "whatsnext" %}} -* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). -* Learn more about [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) - and the [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) - resource types by reading the Audit configuration reference. - +* [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). +* [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +* [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) From cde216e2f4d84ec16f58a39927507b6eaccb4f42 Mon Sep 17 00:00:00 2001 From: Carlos Domingues <11181378+CarlosDomingues@users.noreply.github.com> Date: Mon, 29 Nov 2021 00:43:34 -0300 Subject: [PATCH 007/145] Use tee to write to /etc/bash_completion.d/kubectl --- .../tasks/tools/included/optional-kubectl-configs-bash-linux.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index 949f1922c4..f3ae91fe65 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -37,7 +37,7 @@ You now need to ensure that the kubectl completion script gets sourced in all yo - Add the completion script to the `/etc/bash_completion.d` directory: ```bash - kubectl completion bash >/etc/bash_completion.d/kubectl + echo -e "$(kubectl completion bash)" | sudo tee /etc/bash_completion.d/kubectl > /dev/null ``` If you have an alias for kubectl, you can extend shell completion to work with that alias: From 7efe6cb612bfba54fd7787896569ecb8f79fed34 Mon Sep 17 00:00:00 2001 From: Carlos Domingues <11181378+CarlosDomingues@users.noreply.github.com> Date: Mon, 29 Nov 2021 22:11:31 -0300 Subject: [PATCH 008/145] Remove unecessary "echo" Co-authored-by: Tim Bannister --- .../tasks/tools/included/optional-kubectl-configs-bash-linux.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index f3ae91fe65..5838c5c343 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -37,7 +37,7 @@ You now need to ensure that the kubectl completion script gets sourced in all yo - Add the completion script to the `/etc/bash_completion.d` directory: ```bash - echo -e "$(kubectl completion bash)" | sudo tee /etc/bash_completion.d/kubectl > /dev/null + kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null ``` If you have an alias for kubectl, you can extend shell completion to work with that alias: From 42e485b814f2807fce825581fe79fb89fb05cf2e Mon Sep 17 00:00:00 2001 From: Carlos Domingues <11181378+CarlosDomingues@users.noreply.github.com> Date: Mon, 29 Nov 2021 22:23:54 -0300 Subject: [PATCH 009/145] Use tabs and explicitly say this is for bash only --- .../optional-kubectl-configs-bash-linux.md | 21 +++++++++---------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index 5838c5c343..0024ff8bbc 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -26,19 +26,18 @@ Reload your shell and verify that bash-completion is correctly installed by typi ### Enable kubectl autocompletion +#### Bash + You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this: -- Source the completion script in your `~/.bashrc` file: - - ```bash - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` - -- Add the completion script to the `/etc/bash_completion.d` directory: - - ```bash - kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null - ``` +{{< tabs name="kubectl_bash_autocompletion" >}} +{{{< tab name="User" codelang="bash" >}} +echo 'source <(kubectl completion bash)' >>~/.bashrc +{{< /tab >}} +{{< tab name="System" codelang="bash" >}} +kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null +{{< /tab >}}} +{{< /tabs >}} If you have an alias for kubectl, you can extend shell completion to work with that alias: From 4cbcca7bfaafde15dddf924a4e47ac3dbbb0740c Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 3 Dec 2021 18:51:13 +0900 Subject: [PATCH 010/145] =?UTF-8?q?=E7=A7=98=E5=AF=86-->=E6=A9=9F=E5=AF=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distribute-credentials-secure.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 772ada5e20..4ca7751137 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -13,9 +13,9 @@ min-kubernetes-server-version: v1.6 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -### 秘密データをbase64でエンコードする +### 機密データをbase64でエンコードする -ユーザー名 `my-app` とパスワード `39528$vdg7Jb` の2つの秘密データが必要だとします。 +ユーザー名 `my-app` とパスワード `39528$vdg7Jb` の2つの機密データが必要だとします。 まず、base64エンコーディングツールを使って、ユーザ名とパスワードをbase64表現に変換します。 ここでは、手軽に入手できるbase64プログラムを使った例を紹介します: @@ -24,8 +24,7 @@ echo -n 'my-app' | base64 echo -n '39528$vdg7Jb' | base64 ``` -出力結果によると、ユーザ名のbase64表現は `bXktYXBw`で、 -パスワードのbase64表現は `Mzk1MjgkdmRnN0pi` です。 +出力結果によると、ユーザ名のbase64表現は `bXktYXBw`で、パスワードのbase64表現は `Mzk1MjgkdmRnN0pi` です。 {{< caution >}} OSから信頼されているローカルツールを使用することで、外部ツールのセキュリティリスクを低減することができます。 @@ -96,7 +95,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro `kubectl create secret` の方が便利です。 -## Volume にある秘密情報をアクセスする Pod を作成する +## Volume にある機密情報をアクセスする Pod を作成する これは Pod の作成に使用できる設定ファイルです。 @@ -126,7 +125,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro kubectl exec -i -t secret-test-pod -- /bin/bash ``` -1. 秘密のデータは `/etc/secret-volume` にマウントされたボリュームを介してコンテナに公開されます。 +1. 機密データは `/etc/secret-volume` にマウントされたボリュームを介してコンテナに公開されます。 ディレクトリ `/etc/secret-volume` 中のファイルの一覧を確認する: ```shell From 5bb8a9a721147f398ad28ebd635991d61e6eaeeb Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:52:35 +0900 Subject: [PATCH 011/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 4ca7751137..ea17d467bb 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -35,7 +35,7 @@ OSから信頼されているローカルツールを使用することで、外 ## Secret を作成する -以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイル: +以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイルです: {{< codenew file="pods/inject/secret.yaml" >}} From 5ea6a36bcabb81c8822f31969c0c0810d8d816c3 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:02 +0900 Subject: [PATCH 012/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index ea17d467bb..b6ad2feb5f 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -80,7 +80,7 @@ OSから信頼されているローカルツールを使用することで、外 username: 7 bytes ``` -### kubectl で Secret を作成する +### kubectlでSecretを作成する base64エンコードの手順を省略したい場合は、`kubectl create secret`コマンドで 同じSecretを作成することができます。 From 3662c0d34f7926610a5faee9d2ce26c0f2bb5b15 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:20 +0900 Subject: [PATCH 013/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index b6ad2feb5f..89f187b574 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -58,7 +58,7 @@ OSから信頼されているローカルツールを使用することで、外 test-secret Opaque 2 1m ``` -1. Secret の詳細な情報を取得する: +1. Secretの詳細な情報を取得する: ```shell kubectl describe secret test-secret From 7441a69c1ebbc6034b872484171fa23595a37c19 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:29 +0900 Subject: [PATCH 014/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 89f187b574..d9573d93cc 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -219,7 +219,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro この機能は Kubernetes v1.6 以降から利用可能 {{< /note >}} -* 複数 key-value ペアを含む Secret を作成する +* 複数のkey-valueペアを含むSecretを作成する ```shell kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' From 8eba8a75284eddca28ffa7b69d360996b2850508 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:37 +0900 Subject: [PATCH 015/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index d9573d93cc..46a3b4bd78 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -225,7 +225,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' ``` -* envFromを使用してSecretのすべてのデータをコンテナの環境変数として定義します。Secret のキーが Pod の環境変数名になります。 +* envFromを使用してSecretのすべてのデータをコンテナの環境変数として定義します。SecretのキーがPodの環境変数名になります。 {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} From bf705ea73e2e6a00d1609d46a962fc795eb1fcc8 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:43 +0900 Subject: [PATCH 016/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 46a3b4bd78..fcebac0efd 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -229,7 +229,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} -* Pod を作成する: +* Podを作成する: ```shell kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml From 80d7605c23f4f0faedb1329e14319660eb565b8d Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:51 +0900 Subject: [PATCH 017/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index fcebac0efd..bde9a9dde0 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -255,5 +255,5 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro ## {{% heading "whatsnext" %}} -* [Secrets](/docs/concepts/configuration/secret/) についてもっと知る. +* [Secrets](/docs/concepts/configuration/secret/)についてもっと知る。 * [Volumes](/docs/concepts/storage/volumes/) について. From 5066f135555c1348abc758db74f0922ff758ecba Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:53:55 +0900 Subject: [PATCH 018/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index bde9a9dde0..fe9dab9ee7 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -256,4 +256,4 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro ## {{% heading "whatsnext" %}} * [Secrets](/docs/concepts/configuration/secret/)についてもっと知る。 -* [Volumes](/docs/concepts/storage/volumes/) について. +* [Volumes](/docs/concepts/storage/volumes/)について知る。 From 874d0e3ed06c7bcab2ccc3cba09707f1e03d23a8 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:54:16 +0900 Subject: [PATCH 019/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index fe9dab9ee7..f4cf1aac7d 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -45,7 +45,7 @@ OSから信頼されているローカルツールを使用することで、外 kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml ``` -1. Secret の情報を取得する +1. Secretの情報を取得する ```shell kubectl get secret test-secret From d197a309e0714f3d437e5ebf0860d6ae96c8c7b2 Mon Sep 17 00:00:00 2001 From: Wang Date: Fri, 3 Dec 2021 18:54:46 +0900 Subject: [PATCH 020/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: nasa9084 --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index f4cf1aac7d..b9f2c51a6f 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -33,7 +33,7 @@ OSから信頼されているローカルツールを使用することで、外 -## Secret を作成する +## Secretを作成する 以下はユーザー名とパスワードを保持するSecretを作成するために使用できる設定ファイルです: From 4f30c4178cf8d9e60aa30bb8c2f4948ea5169e92 Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 3 Dec 2021 18:59:07 +0900 Subject: [PATCH 021/145] =?UTF-8?q?=E8=8B=B1=E6=96=87=E3=81=A8=E6=97=A5?= =?UTF-8?q?=E6=9C=AC=E8=AA=9E=E9=96=93=E3=81=AE=E3=82=B9=E3=83=9A=E3=83=BC?= =?UTF-8?q?=E3=82=B9=E3=81=8C=E4=B8=8D=E8=A6=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distribute-credentials-secure.md | 40 +++++++++---------- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index b9f2c51a6f..5d748eeba1 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -82,8 +82,7 @@ OSから信頼されているローカルツールを使用することで、外 ### kubectlでSecretを作成する -base64エンコードの手順を省略したい場合は、`kubectl create secret`コマンドで -同じSecretを作成することができます。 +base64エンコードの手順を省略したい場合は、`kubectl create secret`コマンドで同じSecretを作成することができます。 例えば: @@ -91,23 +90,22 @@ base64エンコードの手順を省略したい場合は、`kubectl create secr kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' ``` -先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、 -`kubectl create secret` の方が便利です。 +先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、`kubectl create secret` の方が便利です。 -## Volume にある機密情報をアクセスする Pod を作成する +## Volumeにある機密情報をアクセスするPodを作成する -これは Pod の作成に使用できる設定ファイルです。 +これはPodの作成に使用できる設定ファイルです。 {{< codenew file="pods/inject/secret-pod.yaml" >}} -1. Pod を作成する: +1. Podを作成する: ```shell kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml ``` -1. Pod がランニング状態にあるのを確認する: +1. Podがランニング状態にあるのを確認する: ```shell kubectl get pod secret-test-pod @@ -119,7 +117,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro secret-test-pod 1/1 Running 0 42m ``` -1. Pod の中にあるコンテナにシェルを実行する +1. Podの中にあるコンテナにシェルを実行する ```shell kubectl exec -i -t secret-test-pod -- /bin/bash @@ -151,27 +149,27 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro 39528$vdg7Jb ``` -## Secret でコンテナの環境変数を定義する +## Secretでコンテナの環境変数を定義する -### 単一の Secret でコンテナの環境変数を定義する +### 単一のSecretでコンテナの環境変数を定義する -* Secret の中で key-value ペアで環境変数を定義する: +* Secretの中でkey-valueペアで環境変数を定義する: ```shell kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' ``` -* Secret で定義された`backend-username`の値をPodの環境変数`SECRET_USERNAME`に割り当てます。 +* Secretで定義された`backend-username`の値をPodの環境変数`SECRET_USERNAME`に割り当てます。 {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}} -* Pod を作成する: +* Podを作成する: ```shell kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml ``` -* コンテナの環境変数 `SECRET_USERNAME` の中身を表示する: +* コンテナの環境変数`SECRET_USERNAME`の中身を表示する: ```shell kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' @@ -182,20 +180,20 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro backend-admin ``` -### 複数の Secret からコンテナの環境変数を定義する +### 複数のSecretからコンテナの環境変数を定義する -* 前述の例と同様に、まず Secret を作成します: +* 前述の例と同様に、まずSecretを作成します: ```shell kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' kubectl create secret generic db-user --from-literal=db-username='db-admin' ``` -* Pod の中で環境変数を定義する: +* Podの中で環境変数を定義する: {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}} -* Pod を作成する: +* Podを作成する: ```shell kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml @@ -213,7 +211,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro ``` -## Secret のすべての key-value ペアを環境変数として設定する +## Secretのすべてのkey-valueペアを環境変数として設定する {{< note >}} この機能は Kubernetes v1.6 以降から利用可能 @@ -235,7 +233,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml ``` -* `username` と `password` コンテナの環境変数を表示する +* `username`と`password`コンテナの環境変数を表示する ```shell kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' From 3b816b6c9bb7aa6cbe6bf451a8a4b399b49ef8bf Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 3 Dec 2021 19:12:48 +0900 Subject: [PATCH 022/145] =?UTF-8?q?=E8=8B=B1=E5=8D=98=E8=AA=9E=E3=81=A8?= =?UTF-8?q?=E6=97=A5=E6=9C=AC=E8=AA=9E=E3=81=AE=E9=96=93=E3=81=AB=E5=8D=8A?= =?UTF-8?q?=E8=A7=92=E3=82=B9=E3=83=9A=E3=83=BC=E3=82=B9=E3=81=AF=E4=B8=8D?= =?UTF-8?q?=E8=A6=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tasks/debug-application-cluster/audit.md | 29 +++++++++---------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index fcd9f7e487..6ed9fd04d8 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -21,8 +21,7 @@ Kubernetesの監査はクラスタ内の一連の行動を記録するセキュ -監査記録は、そのライフサイクルを -[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 +監査記録は、そのライフサイクルを[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 @@ -38,7 +37,7 @@ Kubernetesの監査はクラスタ内の一連の行動を記録するセキュ - `Panic` - パニックが起きたときに発生するイベント。 {{< note >}} -[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)API オブジェクトとは異なります。 +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)APIオブジェクトとは異なります。 {{< /note >}} 監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリ消費量が増加します。 @@ -66,7 +65,7 @@ using the `--audit-policy-file` flag. If the flag is omitted, no events are logg Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal. -`audit-policy-file` フラグを使って、ポリシーを記述したファイルを `kube-apiserver` に渡すことができます。 +`audit-policy-file`フラグを使って、ポリシーを記述したファイルを `kube-apiserver`に渡すことができます。 このフラグが省略された場合イベントは記録されません。 監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 ルールがない(0)ポリシーは不当なものとして扱われます。 @@ -75,7 +74,7 @@ A policy with no (0) rules is treated as illegal. {{< codenew file="audit/audit-policy.yaml" >}} -最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata` レベルで記録することができます。 +最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata`レベルで記録することができます。 ```yaml # Log all requests at the Metadata level. @@ -152,7 +151,7 @@ volumeMounts: readOnly: false ``` -最後に `hostPath` を設定します: +最後に`hostPath`を設定します: ```yaml ... - name: audit @@ -185,9 +184,9 @@ Webhookの設定ファイルは、kubeconfig 形式でサービスのリモー ログバックエンドとwebhookバックエンドの両方がバッチ処理をサポートしています。 webhookを例に、利用可能なフラグの一覧を示します。 -ログバックエンドで同じフラグを取得するには、フラグ名の `webhook` を `log` に置き換えてください。 -デフォルトでは、バッチングは `webhook` では有効で、`log` では無効です。 -同様に、デフォルトでは、スロットリングは `webhook` で有効で、`log` では無効です。 +ログバックエンドで同じフラグを取得するには、フラグ名の`webhook`を`log`に置き換えてください。 +デフォルトでは、バッチングは`webhook`では有効で、`log`では無効です。 +同様に、デフォルトではスロットリングは `webhook` で有効で、`log`では無効です。 - `--audit-webhook-mode` は、バッファリング戦略を定義します。以下のいずれかとなります。 - `batch` - イベントをバッファリングして、非同期にバッチ処理します。これがデフォルトです。 @@ -196,12 +195,12 @@ webhookを例に、利用可能なフラグの一覧を示します。 以下のフラグは `batch` モードでのみ使用されます: -- `--audit-webhook-batch-buffer-size` は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 +- `--audit-webhook-batch-buffer-size`は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 入力イベントの割合がバッファをオーバーフローすると、イベントはドロップされます。 -- `--audit-webhook-batch-max-size` は、1つのバッチに入れるイベントの最大数を定義します。 -- `--audit-webhook-batch-max-wait` は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 -- `--audit-webhook-batch-throttle-qps` は、1秒あたりに生成されるバッチの最大平均数を定義します。 -- `--audit-webhook-batch-throttle-burst` は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 +- `--audit-webhook-batch-max-size`は、1つのバッチに入れるイベントの最大数を定義します。 +- `--audit-webhook-batch-max-wait`は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 +- `--audit-webhook-batch-throttle-qps`は、1秒あたりに生成されるバッチの最大平均数を定義します。 +- `--audit-webhook-batch-throttle-burst`は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 ## パラメータチューニング @@ -230,7 +229,7 @@ logバックエンドとwebhookバックエンドは、ログに記録される - `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 -デフォルトでは、`webhook` と `log` の両方で切り捨ては無効になっていますが、クラスタ管理者は `audit-log-truncate-enabled` または `audit-webhook-truncate-enabled` を設定して、この機能を有効にする必要があります。 +デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスタ管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 ## {{% heading "whatsnext" %}} From 5d7141f9034a846f83fb4a1af1244460ebd410dc Mon Sep 17 00:00:00 2001 From: ixodie Date: Mon, 6 Dec 2021 06:53:02 -0500 Subject: [PATCH 023/145] Kind cleanup - Remove Contiv This domain/URL has no relevant content, is a squatter. Video link on youtube is 5 years old. Product seems to be abandonware. --- content/en/docs/concepts/cluster-administration/networking.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 2b5c398a46..f3cf77507d 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -143,10 +143,6 @@ network complexity required to deploy Kubernetes at scale within AWS. [Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking. Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks. -### Contiv - -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. - ### Contrail / Tungsten Fabric [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. From b9d21bf215eaabc5cee55616e599e06cbf5eaa11 Mon Sep 17 00:00:00 2001 From: ptux Date: Sun, 12 Dec 2021 21:38:36 +0900 Subject: [PATCH 024/145] done --- .../tasks/debug-application-cluster/crictl.md | 408 ++++++++++++++++++ 1 file changed, 408 insertions(+) create mode 100644 content/ja/docs/tasks/debug-application-cluster/crictl.md diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md new file mode 100644 index 0000000000..9d69bff1ac --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -0,0 +1,408 @@ +--- +reviewers: +- ptux +title: crictlによるKubernetesノードのデバッグ +content_type: task +--- + + + + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + +`crictl`はCRI互換のコンテナランタイム用のコマンドラインインターフェイスです。 + +これを使って、Kubernetes ノード上のコンテナランタイムやアプリケーションの検査やデバッグを行うことができます。 +`crictl`とそのソースは[cri-tools](https://github.com/kubernetes-sigs/cri-tools)リポジトリにホストされています。 + +## {{% heading "prerequisites" %}} + + +`crictl`にはCRIランタイムを搭載した Linux が必要です。 + + + + + +## crictlのインストール + +cri-tools [release page](https://github.com/kubernetes-sigs/cri-tools/releases)から、いくつかの異なるアーキテクチャ用の圧縮アーカイブ`crictl`をダウンロードできます。 + +お使いのKubernetesのバージョンに対応するバージョンをダウンロードしてください。 +それを解凍してシステムパス上の`/usr/local/bin/`などの場所に移動します。 + +## 一般的な使い方 + +`crictl`コマンドにはいくつかのサブコマンドとランタイムフラグがあります。 +詳細は`crictl help`または`crictl help`を参照してください。 +`crictl`はデフォルトでは`unix:///var/run/dockershim.sock`に接続します。 + +他のランタイムの場合は、複数の異なる方法でエンドポイントを設定することができます: + +- フラグ`--runtime-endpoint`と`--image-endpoint`の設定により +- 環境変数`CONTAINER_RUNTIME_ENDPOINT`と`IMAGE_SERVICE_ENDPOINT`の設定により +- 設定ファイル`--config=/etc/crictl.yaml`でエンドポイントの設定により + +また、サーバーに接続する際のタイムアウト値を指定したり、デバッグを有効／無効にしたりすることもできます。 +これには、設定ファイルで`timeout`や`debug`を指定するか、`--timeout`や`--debug`のコマンドラインフラグを使用します。 + +現在の設定を表示または編集するには、`/etc/crictl.yaml`の内容を表示または編集します。 + + +```shell +cat /etc/crictl.yaml +runtime-endpoint: unix:///var/run/dockershim.sock +image-endpoint: unix:///var/run/dockershim.sock +timeout: 10 +debug: true +``` + +## crictlコマンドの例 + +以下の例では、いくつかの`crictl`コマンドとその出力例を示しています。 + +{{< warning >}} +実行中のKubernetesクラスターに`crictl`を使ってポッドのサンドボックスやコンテナを作成しても、Kubeletは最終的にそれらを削除します。`crictl` は汎用のワークフローツールではなく、デバッグに便利なツールです。 +{{< /warning >}} + +### podsの一覧 + +すべてのポッドをリストアップ: + +```shell +crictl pods +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 +4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 +a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0 +919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0 +``` + +Podを名前でリストアップします: + +```shell +crictl pods --name nginx-65899c769f-wv2gp +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +Podをラベルでリストアップします: + +```shell +crictl pods --label run=nginx +``` + +出力はこのようになります: + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +### イメージの一覧 + +すべてのイメージをリストアップします: + +```shell +crictl images +``` + +出力はこのようになります: + +``` +IMAGE TAG IMAGE ID SIZE +busybox latest 8c811b4aec35f 1.15MB +k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB +k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB +nginx latest cd5239a0906a6 109MB +``` + +イメージをリポジトリでリストアップします: + +```shell +crictl images nginx +``` + +出力はこのようになります: + +``` +IMAGE TAG IMAGE ID SIZE +nginx latest cd5239a0906a6 109MB +``` + +イメージのIDのみをリストアップします: + +```shell +crictl images -q +``` + +出力はこのようになります: + +``` +sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a +sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 +sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e +sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 +``` + +### List containers + +すべてのコンテナをリストアップします: + +```shell +crictl ps -a +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 +9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0 +``` + +ランニングコンテナをリストアップします: + +``` +crictl ps +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0 +``` + +### 実行中のコンテナでコマンドの実行 + +```shell +crictl exec -i -t 1f73f2d81bf98 ls +``` + +出力はこのようになります: + +``` +bin dev etc home proc root sys tmp usr var +``` + +### コンテナログの取得 + +すべてのコンテナログを取得します: + +```shell +crictl logs 87d3992f84f74 +``` + +出力はこのようになります: + +``` +10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +最新の`N`行のログのみを取得します: + +```shell +crictl logs --tail=1 87d3992f84f74 +``` + +出力はこのようになります: + +``` +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +### Podサンドボックスの実行 + +`crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。 +実行中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止・削除されます。 + +1. 以下のようなJSONファイルを作成します: + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "logDirectory": "/tmp", + "linux": { + } + } + ``` + +2. JSONを適用してサンドボックスを実行するには、`crictl runp`コマンドを使用します: + + ```shell + crictl runp pod-config.json + ``` + + サンドボックスのIDが返されます。 + +### コンテナの作成 + +コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。 + +1. busyboxイメージをプルします: + + ```shell + crictl pull busybox + Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 + ``` + +2. Podとコンテナのコンフィグを作成します: + + **Pod config**: + ```yaml + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + + **Container config**: + ```yaml + { + "metadata": { + "name": "busybox" + }, + "image":{ + "image": "busybox" + }, + "command": [ + "top" + ], + "log_path":"busybox.log", + "linux": { + } + } + ``` + +3. 先に作成されたPodのID、コンテナの設定ファイル、Podの設定ファイルを渡して、コンテナを作成します。コンテナのIDが返されます。 + + ```shell + crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json + ``` + +4. すべてのコンテナをリストアップし、新しく作成されたコンテナのステートが`Created`に設定されていることを確認します: + + ```shell + crictl ps -a + ``` + + 出力はこのようになります: + ``` + CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT + 3e025dd50a72d busybox 32 seconds ago Created busybox 0 + ``` + +### コンテナの起動 + +コンテナを起動するには、そのコンテナのIDを`crictl start`に渡します: + +```shell +crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +出力はこのようになります: + +``` +3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +コンテナの状態が「Running」に設定されていることを確認します: + +```shell +crictl ps +``` + +出力はこのようになります: + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + + + +詳しくは[kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)をご覧ください。 + +## docker cliからcrictlへのマッピング + +以下のマッピング表の正確なバージョンは、`docker cli v1.40`と`crictl v1.19.0`のものです。 +この一覧はすべてを網羅しているわけではないことに注意してください。 +たとえば、`docker cli`の実験的なコマンドは含まれていません。 + +{{< note >}} +CRICTLの出力形式はDocker CLIと似ていますが、いくつかのCLIでは列が欠けています。 +{{< /note >}} + +### デバッグ情報の取得 + +{{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} +docker cli | crictl | 説明 | サポートされていない機能 +-- | -- | -- | -- +`attach` | `attach` | ランニングコンテナにアタッチ | `--detach-keys`, `--sig-proxy` +`exec` | `exec` | ランニングコンテナにコマンドの実行 | `--privileged`, `--user`, `--detach-keys` +`images` | `images` | イメージのリストアップ |   +`info` | `info` | システム全体の情報の表示 |   +`inspect` | `inspect`, `inspecti` | コンテナ、イメージ、タスクの低レベルの情報を返します |   +`logs` | `logs` | コンテナのログを取得します | `--details` +`ps` | `ps` | コンテナのリストアップ |   +`stats` | `stats` | コンテナのリソース使用状況をライブで表示 | Column: NET/BLOCK I/O, PIDs +`version` | `version` | ランタイム（Docker、ContainerD、その他）のバージョン情報を表示します |   +{{< /table >}} + +### 変更を行います + +{{< table caption="mapping from docker cli to crictl - perform changes" >}} +docker cli | crictl | 説明 | サポートされていない機能 +-- | -- | -- | -- +`create` | `create` | 新しいコンテナを作成します |   +`kill` | `stop` (timeout = 0) | 1つ以上の実行中のコンテナを停止します | `--signal` +`pull` | `pull` | レジストリからイメージやリポジトリをプルします | `--all-tags`, `--disable-content-trust` +`rm` | `rm` | 1つまたは複数のコンテナを削除します |   +`rmi` | `rmi` | 1つまたは複数のイメージを削除します |   +`run` | `run` | 新しいコンテナでコマンドを実行 |   +`start` | `start` | 停止した1つまたは複数のコンテナを起動 | `--detach-keys` +`stop` | `stop` | 実行中の1つまたは複数のコンテナの停止 |   +`update` | `update` | 1つまたは複数のコンテナの構成を更新 | `--restart`、`--blkio-weight`とその他 +{{< /table >}} + +### crictlでのみ対応 + +{{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} +crictl | 説明 +-- | -- +`imagefsinfo` | イメージファイルシステムの情報を返Pod +`inspectp` | 1つまたは複数のPodの状態を表示します +`port-forward` | ローカルポートをPodに転送します +`runp` | 新しいPodを実行します +`rmp` | 1つまたは複数のPodを削除します +`stopp` | 稼働中の1つまたは複数のPodを停止します +{{< /table >}} \ No newline at end of file From 63d5e34d21661f807bda5c2b658b84504c75c783 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 15 Dec 2021 09:05:08 +0900 Subject: [PATCH 025/145] Update crictl.md --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 9d69bff1ac..8b85605b59 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -231,7 +231,6 @@ crictl logs --tail=1 87d3992f84f74 ### Podサンドボックスの実行 `crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。 -実行中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止・削除されます。 1. 以下のようなJSONファイルを作成します: @@ -405,4 +404,4 @@ crictl | 説明 `runp` | 新しいPodを実行します `rmp` | 1つまたは複数のPodを削除します `stopp` | 稼働中の1つまたは複数のPodを停止します -{{< /table >}} \ No newline at end of file +{{< /table >}} From 454031bc32c06bd8314d92ca1093625f737fd81f Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 17 Dec 2021 13:23:36 +0900 Subject: [PATCH 026/145] deletion of these lines is rejected by the upstream pr #30880 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 8b85605b59..310270d7c1 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -231,6 +231,7 @@ crictl logs --tail=1 87d3992f84f74 ### Podサンドボックスの実行 `crictl`を使ってPodサンドボックスを実行することは、コンテナのランタイムをデバッグするのに便利です。 +稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 1. 以下のようなJSONファイルを作成します: @@ -259,6 +260,7 @@ crictl logs --tail=1 87d3992f84f74 ### コンテナの作成 コンテナの作成に`crictl`を使うと、コンテナのランタイムをデバッグするのに便利です。 +稼働中のKubernetesクラスタでは、サンドボックスは最終的にKubeletによって停止され、削除されます。 1. busyboxイメージをプルします: From 1e03a8789afe73caed190d4d02491d73c90b117e Mon Sep 17 00:00:00 2001 From: ptux Date: Fri, 17 Dec 2021 14:59:12 +0900 Subject: [PATCH 027/145] fix typo --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 310270d7c1..947a1b3a14 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -400,7 +400,7 @@ docker cli | crictl | 説明 | サポートされていない機能 {{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} crictl | 説明 -- | -- -`imagefsinfo` | イメージファイルシステムの情報を返Pod +`imagefsinfo` | イメージファイルシステムの情報を返します `inspectp` | 1つまたは複数のPodの状態を表示します `port-forward` | ローカルポートをPodに転送します `runp` | 新しいPodを実行します From 758a49065537d471275c50a4abfdf60b668636c9 Mon Sep 17 00:00:00 2001 From: ptux Date: Tue, 28 Dec 2021 10:24:54 +0900 Subject: [PATCH 028/145] change to English reference --- .../kube-apiserver.md | 1856 +++-------------- 1 file changed, 254 insertions(+), 1602 deletions(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md index 96d0229b43..77b354dc70 100644 --- a/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/ja/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + + ## {{% heading "synopsis" %}} - -Kubernetes API 服务器验证并配置 API 对象的数据， -这些对象包括 pods、services、replicationcontrollers 等。 -API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端， -所有其他组件都通过该前端进行交互。 ``` kube-apiserver [flags] @@ -36,7 +32,7 @@ kube-apiserver [flags] ## {{% heading "options" %}} - +
@@ -47,2489 +43,1145 @@ kube-apiserver [flags] - + - + - + - + - + - - + - + - + - + - + - + - + - + - + - - - + + + + - + - + - + - + - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - + - + - + - + - + - + - + + + + + + + + - + - + - + - + - + - + - +
--add-dir-header
- -

如果为 true，则将文件目录添加到日志消息的标题中

-

If true, adds the file directory to the header of the log messages
--admission-control-config-file string
- -

包含准入控制配置的文件。

-

File with admission control configuration.
--advertise-address string
- -

-向集群成员通知 apiserver 消息的 IP 地址。 -这个地址必须能够被集群中其他成员访问。 -如果 IP 地址为空，将会使用 --bind-address， -如果未指定 --bind-address，将会使用主机的默认接口地址。 -

-

The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used.
--allow-metric-labels stringToString     默认值：[]--allow-metric-labels stringToString     Default: []

- -允许使用的指标标签到指标值的映射列表。键的格式为 <MetricName>,<LabelName>. -值的格式为 <allowed_value>,<allowed_value>...。 -例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。 -

The map from metric-label to value allow-list of this label. The key's format is <MetricName>,<LabelName>. The value's format is <allowed_value>,<allowed_value>...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.
--allow-privileged
- -如果为 true, 将允许特权容器。[默认值=false] -

If true, allow privileged containers. [default=false]
--alsologtostderr
- -在向文件输出日志的同时，也将日志写到标准输出。 -

log to standard error as well as files
--anonymous-auth     默认值：true--anonymous-auth     Default: true
- -启用到 API 服务器的安全端口的匿名请求。 -未被其他认证方法拒绝的请求被当做匿名请求。 -匿名请求的用户名为 system:anonymous， -用户组名为 system:unauthenticated。 -

Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated.
--api-audiences strings
- -API 的标识符。 -服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。 -如果配置了 --service-account-issuer 标志，但未配置此标志， -则此字段默认为包含发布者 URL 的单个元素列表。 -

Identifiers of the API. The service account token authenticator will validate that tokens used against the API are bound to at least one of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL.
--apiserver-count int     默认值：1--apiserver-count int     Default: 1
- -集群中运行的 API 服务器数量，必须为正数。 -（在启用 --endpoint-reconciler-type=master-count 时使用。） -

The number of apiservers running in the cluster, must be a positive number. (In use when --endpoint-reconciler-type=master-count is enabled.)
--audit-log-batch-buffer-size int     默认值：10000--audit-log-batch-buffer-size int     Default: 10000
- -批处理和写入之前用于存储事件的缓冲区大小。 -仅在批处理模式下使用。 -

The size of the buffer to store events before batching and writing. Only used in batch mode.
--audit-log-batch-max-size int     默认值：1
- -每个批次的最大大小。仅在批处理模式下使用。 ---audit-log-batch-max-size int     Default: 1

The maximum size of a batch. Only used in batch mode.
--audit-log-batch-max-wait duration
- -强制写入尚未达到最大大小的批次之前要等待的时间。 -仅在批处理模式下使用。 -

The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.
--audit-log-batch-throttle-burst int
- -如果之前未使用 ThrottleQPS，则为同时发送的最大请求数。 -仅在批处理模式下使用。 -

Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.
--audit-log-batch-throttle-enable
- -是否启用了批量限制。仅在批处理模式下使用。 -

Whether batching throttling is enabled. Only used in batch mode.
--audit-log-batch-throttle-qps float
- -每秒的最大平均批次数。仅在批处理模式下使用。 -

Maximum average number of batches per second. Only used in batch mode.
--audit-log-compress
- -若设置了此标志，则被轮换的日志文件会使用 gzip 压缩。 -

If set, the rotated log files will be compressed using gzip.
--audit-log-format string     默认值："json" --audit-log-format string     Default: "json"
- -所保存的审计格式。 -"legacy" 表示每行一个事件的文本格式。"json" 表示结构化的 JSON 格式。 -已知格式为 legacy，json。 -

Format of saved audits. "legacy" indicates 1-line text format for each event. "json" indicates structured json format. Known formats are legacy,json.
--audit-log-maxage int
- -根据文件名中编码的时间戳保留旧审计日志文件的最大天数。 -

The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
--audit-log-maxbackup int
- -要保留的旧的审计日志文件个数上限。 -

The maximum number of old audit log files to retain.
--audit-log-maxsize int
- -轮换之前，审计日志文件的最大大小（以兆字节为单位）。 -

The maximum size in megabytes of the audit log file before it gets rotated.
--audit-log-mode string     默认值："blocking"--audit-log-mode string     Default: "blocking"
- -用来发送审计事件的策略。 -阻塞（blocking）表示发送事件应阻止服务器响应。 -批处理（batch）会导致后端异步缓冲和写入事件。 -已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 -

Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict.
--audit-log-path string
- -如果设置，则所有到达 API 服务器的请求都将记录到该文件中。 -"-" 表示标准输出。 -

If set, all requests coming to the apiserver will be logged to this file. '-' means standard out.
--audit-log-truncate-enabled
- -是否启用事件和批次截断。 -

Whether event and batch truncating is enabled.
--audit-log-truncate-max-batch-size int     默认值：10485760--audit-log-truncate-max-batch-size int     Default: 10485760
- -发送到下层后端的每批次的最大数据量。 -实际的序列化大小可能会增加数百个字节。 -如果一个批次超出此限制，则将其分成几个较小的批次。 -

Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size.
--audit-log-truncate-max-event-size int     默认值：102400--audit-log-truncate-max-event-size int     Default: 102400
- -发送到下层后端的每批次的最大数据量。 -如果事件的大小大于此数字，则将删除第一个请求和响应； -如果这样做没有减小足够大的程度，则将丢弃事件。 -

Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded.
--audit-log-version string     默认值："audit.k8s.io/v1"--audit-log-version string     Default: "audit.k8s.io/v1"
- -用于对写入日志的审计事件执行序列化的 API 组和版本。 -

API group and version used for serializing audit events written to log.
--audit-policy-file string
- -定义审计策略配置的文件的路径。 -

Path to the file that defines the audit policy configuration.
--audit-webhook-batch-buffer-size int     默认值：10000--audit-webhook-batch-buffer-size int     Default: 10000
- -划分批次和写入之前用于存储事件的缓冲区大小。 -仅在批处理模式下使用。 -

The size of the buffer to store events before batching and writing. Only used in batch mode.
--audit-webhook-batch-max-size int     默认值：400--audit-webhook-batch-max-size int     Default: 400
- -批次的最大大小。 -仅在批处理模式下使用。 -

The maximum size of a batch. Only used in batch mode.
--audit-webhook-batch-max-wait duration     默认值：30s--audit-webhook-batch-max-wait duration     Default: 30s
- -强制写入尚未达到最大大小的批处理之前要等待的时间。 -仅在批处理模式下使用。 -

The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.
--audit-webhook-batch-throttle-burst int     默认值：15--audit-webhook-batch-throttle-burst int     Default: 15
- -如果之前未使用 ThrottleQPS，同时发送的最大请求数。 -仅在批处理模式下使用。 -

Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.
--audit-webhook-batch-throttle-enable     默认值：true--audit-webhook-batch-throttle-enable     Default: true
- -是否启用了批量限制。仅在批处理模式下使用。 -

Whether batching throttling is enabled. Only used in batch mode.
--audit-webhook-batch-throttle-qps float32     默认值：10--audit-webhook-batch-throttle-qps float     Default: 10
- -每秒的最大平均批次数。仅在批处理模式下使用。 -

Maximum average number of batches per second. Only used in batch mode.
--audit-webhook-config-file string
- -定义审计 webhook 配置的 kubeconfig 格式文件的路径。 +

Path to a kubeconfig formatted file that defines the audit webhook configuration.
--audit-webhook-initial-backoff duration     默认值：10s--audit-webhook-initial-backoff duration     Default: 10s
- -重试第一个失败的请求之前要等待的时间。 -

The amount of time to wait before retrying the first failed request.
--audit-webhook-mode string     默认值："batch"--audit-webhook-mode string     Default: "batch"
- -发送审计事件的策略。 -阻止（Blocking）表示发送事件应阻止服务器响应。 -批处理（Batch）导致后端异步缓冲和写入事件。 -已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 -

Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict.
--audit-webhook-truncate-enabled
- -是否启用事件和批处理截断。 -

Whether event and batch truncating is enabled.
--audit-webhook-truncate-max-batch-size int     默认值：10485760--audit-webhook-truncate-max-batch-size int     Default: 10485760
- -发送到下层后端的批次的最大数据量。 -实际的序列化大小可能会增加数百个字节。 -如果一个批次超出此限制，则将其分成几个较小的批次。 -

Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size.
--audit-webhook-truncate-max-event-size int     默认值：102400--audit-webhook-truncate-max-event-size int     Default: 102400
- -发送到下层后端的批次的最大数据量。 -如果事件的大小大于此数字，则将删除第一个请求和响应； -如果事件和事件的大小没有减小到一定幅度，则将丢弃事件。 -

Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded.
--audit-webhook-version string     默认值："audit.k8s.io/v1" ---audit-webhook-version string     Default: "audit.k8s.io/v1"
- -用于序列化写入 Webhook 的审计事件的 API 组和版本。 -

API group and version used for serializing audit events written to webhook.
--authentication-token-webhook-cache-ttl duration     2m0s--authentication-token-webhook-cache-ttl duration     Default: 2m0s
- -对来自 Webhook 令牌身份验证器的响应的缓存时间。 -

The duration to cache responses from the webhook token authenticator.
--authentication-token-webhook-config-file string
- -包含 Webhook 配置的 kubeconfig 格式文件，用于进行令牌认证。 -API 服务器将查询远程服务，以对持有者令牌进行身份验证。 -

File with webhook configuration for token authentication in kubeconfig format. The API server will query the remote service to determine authentication for bearer tokens.
--authentication-token-webhook-version string     默认值："v1beta1" ---authentication-token-webhook-version string     Default: "v1beta1"
- -与 Webhook 之间交换 authentication.k8s.io TokenReview 时使用的 API 版本。 -

The API version of the authentication.k8s.io TokenReview to send to and expect from the webhook.
--authorization-mode stringSlice     默认值："AlwaysAllow"--authorization-mode strings     Default: "AlwaysAllow"
- -在安全端口上进行鉴权的插件的顺序列表。 -逗号分隔的列表：AlwaysAllow、AlwaysDeny、ABAC、Webhook、RBAC、Node。 -

Ordered list of plug-ins to do authorization on secure port. Comma-delimited list of: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.
--authorization-policy-file string
- -包含鉴权策略的文件，其内容为分行 JSON 格式， -在安全端口上与 --authorization-mode=ABAC 一起使用。 -

File with authorization policy in json line by line format, used with --authorization-mode=ABAC, on the secure port.
--authorization-webhook-cache-authorized-ttl duration     默认值：5m0s--authorization-webhook-cache-authorized-ttl duration     Default: 5m0s
- -对来自 Webhook 鉴权组件的 “授权（authorized）” 响应的缓存时间。 -

The duration to cache 'authorized' responses from the webhook authorizer.
--authorization-webhook-cache-unauthorized-ttl duration     默认值：30s--authorization-webhook-cache-unauthorized-ttl duration     Default: 30s
- -对来自 Webhook 鉴权模块的 “未授权（unauthorized）” 响应的缓存时间。 -

The duration to cache 'unauthorized' responses from the webhook authorizer.
--authorization-webhook-config-file string
- -包含 Webhook 配置的文件，其格式为 kubeconfig， -与 --authorization-mode=Webhook 一起使用。 -API 服务器将查询远程服务，以对 API 服务器的安全端口的访问执行鉴权。 -

File with webhook configuration in kubeconfig format, used with --authorization-mode=Webhook. The API server will query the remote service to determine access on the API server's secure port.
--authorization-webhook-version string     默认值："v1beta1"
--authorization-webhook-version string     Default: "v1beta1"
- -与 Webhook 之间交换 authorization.k8s.io SubjectAccessReview 时使用的 API 版本。 -

The API version of the authorization.k8s.io SubjectAccessReview to send to and expect from the webhook.
--azure-container-registry-config string
- -包含 Azure 容器仓库配置信息的文件的路径。 -

Path to the file containing Azure container registry configuration information.
--bind-address string     默认值："0.0.0.0"--bind-address string     Default: 0.0.0.0
- -用来监听 --secure-port 端口的 IP 地址。 -集群的其余部分以及 CLI/web 客户端必须可以访问所关联的接口。 -如果为空白或未指定地址（0.0.0.0 或 ::），则将使用所有接口。 -

The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.
--cert-dir string     默认值："/var/run/kubernetes"--cert-dir string     Default: "/var/run/kubernetes"
- -TLS 证书所在的目录。 -如果提供了 --tls-cert-file 和 --tls-private-key-file -标志值，则将忽略此标志。 -

The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.
--client-ca-file string
- -如果已设置，则使用与客户端证书的 CommonName 对应的标识对任何出示由 -client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。 -

If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--cloud-config string
- -云厂商配置文件的路径。空字符串表示无配置文件。 -

The path to the cloud provider configuration file. Empty string for no configuration file.
--cloud-provider string
- -云服务提供商。空字符串表示没有云厂商。 -

The provider for cloud services. Empty string for no provider.
--cloud-provider-gce-l7lb-src-cidrs cidrs     默认值："130.211.0.0/22,35.191.0.0/16"--cloud-provider-gce-l7lb-src-cidrs cidrs     Default: 130.211.0.0/22,35.191.0.0/16
- -在 GCE 防火墙中打开 CIDR，以进行第 7 层负载均衡流量代理和健康状况检查。 -

CIDRs opened in GCE firewall for L7 LB traffic proxy & health checks
--contention-profiling
- -如果启用了性能分析，则启用锁争用性能分析。 -

Enable lock contention profiling, if profiling is enabled
--cors-allowed-origins strings
- -CORS 允许的来源清单，以逗号分隔。 -允许的来源可以是支持子域匹配的正则表达式。 -如果此列表为空，则不会启用 CORS。 -

List of allowed origins for CORS, comma separated. An allowed origin can be a regular expression to support subdomain matching. If this list is empty CORS will not be enabled.
--default-not-ready-toleration-seconds int     默认值：300--default-not-ready-toleration-seconds int     Default: 300
- -对污点 NotReady:NoExecute 的容忍时长（以秒计）。 -默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 -

Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
--default-unreachable-toleration-seconds int     默认值：300--default-unreachable-toleration-seconds int     Default: 300
- -对污点 Unreachable:NoExecute 的容忍时长（以秒计） -默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 -

Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.
--default-watch-cache-size int     默认值：100--default-watch-cache-size int     Default: 100
- -默认监听（watch）缓存大小。 -如果为零，则将为没有设置默认监视大小的资源禁用监视缓存。 -

Default watch cache size. If zero, watch cache will be disabled for resources that do not have a default watch size set.
--delete-collection-workers int     默认值： 1--delete-collection-workers int     Default: 1
- -为 DeleteCollection 调用而产生的工作线程数。 -这些用于加速名字空间清理。 -

Number of workers spawned for DeleteCollection call. These are used to speed up namespace cleanup.
--disable-admission-plugins strings
- -尽管位于默认启用的插件列表中（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）仍须被禁用的插件。 -
取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook。 -
该标志中插件的顺序无关紧要。 -

admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
--disabled-metrics strings
- -此标志为行为不正确的度量指标提供一种处理方案。 -你必须提供完全限定的指标名称才能将其禁止。 -声明：禁用度量值的行为优先于显示已隐藏的度量值。 -

This flag provides an escape hatch for misbehaving metrics. You must provide the fully qualified metric name in order to disable it. Disclaimer: disabling metrics is higher in precedence than showing hidden metrics.
--egress-selector-config-file string
- -带有 API 服务器出站选择器配置的文件。 -

File with apiserver egress selector configuration.
--enable-admission-plugins stringSlice--enable-admission-plugins strings
- -除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的插件 -
取值为逗号分隔的准入插件列表：AlwaysAdmit、AlwaysDeny、AlwaysPullImages、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、DefaultStorageClass、DefaultTolerationSeconds、DenyServiceExternalIPs、EventRateLimit、ExtendedResourceToleration、ImagePolicyWebhook、LimitPodHardAntiAffinityTopology、LimitRanger、MutatingAdmissionWebhook、NamespaceAutoProvision、NamespaceExists、NamespaceLifecycle、NodeRestriction、OwnerReferencesPermissionEnforcement、PersistentVolumeClaimResize、PersistentVolumeLabel、PodNodeSelector、PodSecurityPolicy、PodTolerationRestriction、Priority、ResourceQuota、RuntimeClass、SecurityContextDeny、ServiceAccount、StorageObjectInUseProtection、TaintNodesByCondition、ValidatingAdmissionWebhook -
该标志中插件的顺序无关紧要。 -

admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
--enable-aggregator-routing
- -允许聚合器将请求路由到端点 IP 而非集群 IP。 -

Turns on aggregator routing requests to endpoints IP rather than cluster IP.
--enable-bootstrap-token-auth
- -启用以允许将 "kube-system" 名字空间中类型为 "bootstrap.kubernetes.io/token" -的 Secret 用于 TLS 引导身份验证。 -

Enable to allow secrets of type 'bootstrap.kubernetes.io/token' in the 'kube-system' namespace to be used for TLS bootstrapping authentication.
--enable-garbage-collector     默认值：true--enable-garbage-collector     Default: true
- -启用通用垃圾收集器。必须与 kube-controller-manager 的相应标志同步。 -

Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-controller-manager.
--enable-priority-and-fairness     默认值：true--enable-priority-and-fairness     Default: true
- -如果为 true 且启用了 APIPriorityAndFairness 特性门控， -请使用增强的处理程序替换 max-in-flight 处理程序， -以便根据优先级和公平性完成排队和调度。 -

If true and the APIPriorityAndFairness feature gate is enabled, replace the max-in-flight handler with an enhanced one that queues and dispatches with priority and fairness
--encryption-provider-config string
- -包含加密提供程序配置信息的文件，用在 etcd 中所存储的 Secret 上。 -

The file containing configuration for encryption providers to be used for storing secrets in etcd
--endpoint-reconciler-type string     默认值："lease"--endpoint-reconciler-type string     Default: "lease"
- -使用端点协调器（master-count、lease 或 none）。 -

Use an endpoint reconciler (master-count, lease, none)
--etcd-cafile string
- -用于保护 etcd 通信的 SSL 证书颁发机构文件。 -

SSL Certificate Authority file used to secure etcd communication.
--etcd-certfile string
- -用于保护 etcd 通信的 SSL 证书文件。 -

SSL certification file used to secure etcd communication.
--etcd-compaction-interval duration     默认值：5m0s--etcd-compaction-interval duration     Default: 5m0s
- -压缩请求的间隔。 -如果为0，则禁用来自 API 服务器的压缩请求。 -

The interval of compaction requests. If 0, the compaction request from apiserver is disabled.
--etcd-count-metric-poll-period duration     默认值：1m0s--etcd-count-metric-poll-period duration     Default: 1m0s
- -针对每种类型的资源数量轮询 etcd 的频率。 -0 值表示禁用度量值收集。 -

Frequency of polling etcd for number of resources per type. 0 disables the metric collection.
--etcd-db-metric-poll-interval duration     默认值：30s--etcd-db-metric-poll-interval duration     Default: 30s
- -轮询 etcd 和更新度量值的请求间隔。0 值表示禁用度量值收集。 -

The interval of requests to poll etcd and update metric. 0 disables the metric collection
--etcd-healthcheck-timeout duration      -检查 etcd 健康状况时使用的超时时长。 -

The timeout to use when checking etcd health.
--etcd-keyfile string
- -用于保护 etcd 通信的 SSL 密钥文件。 -

SSL key file used to secure etcd communication.
--etcd-prefix string     默认值："/registry"--etcd-prefix string     Default: "/registry"
- -要在 etcd 中所有资源路径之前添加的前缀。 -

The prefix to prepend to all resource paths in etcd.
--etcd-servers strings
- -要连接的 etcd 服务器列表（scheme://ip:port），以逗号分隔。 -

List of etcd servers to connect with (scheme://ip:port), comma separated.
--etcd-servers-overrides strings
- -etcd 服务器针对每个资源的重载设置，以逗号分隔。 -单个替代格式：组/资源#服务器（group/resource#servers）， -其中服务器是 URL，以分号分隔。 -

Per-resource etcd servers overrides, comma separated. The individual override format: group/resource#servers, where servers are URLs, semicolon separated. Note that this applies only to resources compiled into this server binary.
--event-ttl duration     默认值：1h0m0s--event-ttl duration     Default: 1h0m0s
- -事件的保留时长。 -

Amount of time to retain events.
--experimental-logging-sanitization
- -[试验性功能] 启用此标志时，被标记为敏感的字段（密码、密钥、令牌）都不会被日志输出。
-运行时的日志清理可能会引入相当程度的计算开销，因此不应该在产品环境中启用。 -

[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens).
Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.
--external-hostname string
- -为此主机生成外部化 UR L时要使用的主机名（例如 Swagger API 文档或 OpenID 发现）。 -

The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs or OpenID Discovery).
--feature-gates <逗号分隔的 'key=True|False' 键值对>--feature-gates <comma-separated 'key=True|False' pairs>
- -

一组 key=value 对，用来描述测试性/试验性功能的特性门控。可选项有： -APIListChunking=true|false (BETA - 默认值=true)
-APIPriorityAndFairness=true|false (BETA - 默认值=true)
-APIResponseCompression=true|false (BETA - 默认值=true)
-APIServerIdentity=true|false (ALPHA - 默认值=false)
-AllAlpha=true|false (ALPHA - 默认值=false)
-AllBeta=true|false (BETA - 默认值=false)
-AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
-AppArmor=true|false (BETA - 默认值=true)
-BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
-BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
-CPUManager=true|false (BETA - 默认值=true)
-CSIInlineVolume=true|false (BETA - 默认值=true)
-CSIMigration=true|false (BETA - 默认值=true)
-CSIMigrationAWS=true|false (BETA - 默认值=false)
-CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
-CSIMigrationAzureFile=true|false (BETA - 默认值=false)
-CSIMigrationGCE=true|false (BETA - 默认值=false)
-CSIMigrationOpenStack=true|false (BETA - 默认值=true)
-CSIMigrationvSphere=true|false (BETA - 默认值=false)
-CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
-CSIServiceAccountToken=true|false (BETA - 默认值=true)
-CSIStorageCapacity=true|false (BETA - 默认值=true)
-CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
-CSIVolumeHealth=true|false (ALPHA - 默认值=false)
-ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
-ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
-CronJobControllerV2=true|false (BETA - 默认值=true)
-CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
-DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
-DefaultPodTopologySpread=true|false (BETA - 默认值=true)
-DevicePlugins=true|false (BETA - 默认值=true)
-DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
-DownwardAPIHugePages=true|false (BETA - 默认值=false)
-DynamicKubeletConfig=true|false (BETA - 默认值=true)
-EfficientWatchResumption=true|false (BETA - 默认值=true)
-EndpointSliceProxying=true|false (BETA - 默认值=true)
-EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
-EphemeralContainers=true|false (ALPHA - 默认值=false)
-ExpandCSIVolumes=true|false (BETA - 默认值=true)
-ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
-ExpandPersistentVolumes=true|false (BETA - 默认值=true)
-ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
-GenericEphemeralVolume=true|false (BETA - 默认值=true)
-GracefulNodeShutdown=true|false (BETA - 默认值=true)
-HPAContainerMetrics=true|false (ALPHA - 默认值=false)
-HPAScaleToZero=true|false (ALPHA - 默认值=false)
-HugePageStorageMediumSize=true|false (BETA - 默认值=true)
-IPv6DualStack=true|false (BETA - 默认值=true)
-InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
-InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
-InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
-InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
-InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
-InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
-IndexedJob=true|false (ALPHA - 默认值=false)
-IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
-KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
-KubeletPodResources=true|false (BETA - 默认值=true)
-KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
-LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
-LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
-LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
-MemoryManager=true|false (ALPHA - 默认值=false)
-MixedProtocolLBService=true|false (ALPHA - 默认值=false)
-NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
-NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
-NonPreemptingPriority=true|false (BETA - 默认值=true)
-PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
-PodDeletionCost=true|false (ALPHA - 默认值=false)
-PodOverhead=true|false (BETA - 默认值=true)
-PreferNominatedNode=true|false (ALPHA - 默认值=false)
-ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
-ProcMountType=true|false (ALPHA - 默认值=false)
-QOSReserved=true|false (ALPHA - 默认值=false)
-RemainingItemCount=true|false (BETA - 默认值=true)
-RemoveSelfLink=true|false (BETA - 默认值=true)
-RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
-ServerSideApply=true|false (BETA - 默认值=true)
-ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
-ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
-ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
-ServiceTopology=true|false (ALPHA - 默认值=false)
-SetHostnameAsFQDN=true|false (BETA - 默认值=true)
-SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
-StorageVersionAPI=true|false (ALPHA - 默认值=false)
-StorageVersionHash=true|false (BETA - 默认值=true)
-SuspendJob=true|false (ALPHA - 默认值=false)
-TTLAfterFinished=true|false (BETA - 默认值=true)
-TopologyAwareHints=true|false (ALPHA - 默认值=false)
-TopologyManager=true|false (BETA - 默认值=true)
-ValidateProxyRedirects=true|false (BETA - 默认值=true)
-VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
-WarningHeaders=true|false (BETA - 默认值=true)
-WinDSR=true|false (ALPHA - 默认值=false)
-WinOverlay=true|false (BETA - 默认值=true)
-WindowsEndpointSliceProxying=true|false (BETA - 默认值=true)

-

A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (ALPHA - default=false)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
CSIMigrationAzureDisk=true|false (BETA - default=false)
CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
CSIVolumeHealth=true|false (ALPHA - default=false)
CSRDuration=true|false (BETA - default=true)
ConfigurableFSGroupPolicy=true|false (BETA - default=true)
ControllerManagerLeaderMigration=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DefaultPodTopologySpread=true|false (BETA - default=true)
DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=false)
EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GenericEphemeralVolume=true|false (BETA - default=true)
GracefulNodeShutdown=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
IPv6DualStack=true|false (BETA - default=true)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
IndexedJob=true|false (BETA - default=true)
IngressClassNamespacedParams=true|false (BETA - default=true)
JobTrackingWithFinalizers=true|false (ALPHA - default=false)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
NetworkPolicyEndPort=true|false (BETA - default=true)
NodeSwap=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
PodAffinityNamespaceSelector=true|false (BETA - default=true)
PodDeletionCost=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
PodSecurity=true|false (ALPHA - default=false)
PreferNominatedNode=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
ServiceLBNodePortControl=true|false (BETA - default=true)
ServiceLoadBalancerClass=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
SuspendJob=true|false (BETA - default=true)
TTLAfterFinished=true|false (BETA - default=true)
TopologyAwareHints=true|false (ALPHA - default=false)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (ALPHA - default=false)
--goaway-chance float
- -为防止 HTTP/2 客户端卡在单个 API 服务器上，可启用随机关闭连接（GOAWAY）。 -客户端的其他运行中请求将不会受到影响，并且客户端将重新连接， -可能会在再次通过负载平衡器后登陆到其他 API 服务器上。 -此参数设置将发送 GOAWAY 的请求的比例。 -具有单个 API 服务器或不使用负载平衡器的群集不应启用此功能。 -最小值为0（关闭），最大值为 .02（1/50 请求）； 建议使用 .001（1/1000）。 -

To prevent HTTP/2 clients from getting stuck on a single apiserver, randomly close a connection (GOAWAY). The client's other in-flight requests won't be affected, and the client will reconnect, likely landing on a different apiserver after going through the load balancer again. This argument sets the fraction of requests that will be sent a GOAWAY. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. Min is 0 (off), Max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.
-h, --help
- -kube-apiserver 的帮助命令 -

help for kube-apiserver
--http2-max-streams-per-connection int
- -服务器为客户端提供的 HTTP/2 连接中最大流数的限制。 -零表示使用 GoLang 的默认值。 -

The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.
--identity-lease-duration-seconds int     默认值：3600--identity-lease-duration-seconds int     Default: 3600
- -kube-apiserver 租约时长（按秒计），必须是正数。 -（当 APIServerIdentity 特性门控被启用时使用此标志值） -

The duration of kube-apiserver lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.)
--identity-lease-renew-interval-seconds int     默认值：10--identity-lease-renew-interval-seconds int     Default: 10
- -kube-apiserver 对其租约进行续期的时间间隔（按秒计），必须是正数。 -（当 APIServerIdentity 特性门控被启用时使用此标志值） -

The interval of kube-apiserver renewing its lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.)
--kubelet-certificate-authority string
- -证书颁发机构的证书文件的路径。 -

Path to a cert file for the certificate authority.
--kubelet-client-certificate string
- -TLS 的客户端证书文件的路径。 -

Path to a client cert file for TLS.
--kubelet-client-key string
- -TLS 客户端密钥文件的路径。 -

Path to a client key file for TLS.
--kubelet-preferred-address-types strings     默认值：Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP--kubelet-preferred-address-types strings     Default: "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP"
- -用于 kubelet 连接的首选 NodeAddressTypes 列表。 -

List of the preferred NodeAddressTypes to use for kubelet connections.
--kubelet-timeout duration     默认值：5s--kubelet-timeout duration     Default: 5s
- -kubelet 操作超时时间。 -

Timeout for kubelet operations.
--kubernetes-service-node-port int
- -如果非零，那么 Kubernetes 主服务（由 apiserver 创建/维护）将是 NodePort 类型， -使用它作为端口的值。 -如果为零，则 Kubernetes 主服务将为 ClusterIP 类型。 -

If non-zero, the Kubernetes master service (which apiserver creates/maintains) will be of type NodePort, using this as the value of the port. If zero, the Kubernetes master service will be of type ClusterIP.
--lease-reuse-duration-seconds int     默认值：60--lease-reuse-duration-seconds int     Default: 60
- -每个租约被重用的时长。 -如果此值比较低，可以避免大量对象重用此租约。 -注意，如果此值过小，可能导致存储层出现性能问题。 -

The time in seconds that each lease is reused. A lower value could avoid large number of objects reusing the same lease. Notice that a too small value may cause performance problems at storage layer.
--livez-grace-period duration
- -此选项代表 API 服务器完成启动序列并生效所需的最长时间。 -从 API 服务器的启动时间到这段时间为止， -/livez 将假定未完成的启动后钩子将成功完成，因此返回 true。 -

This option represents the maximum amount of time it should take for apiserver to complete its startup sequence and become live. From apiserver's start time to when this amount of time has elapsed, /livez will assume that unfinished post-start hooks will complete successfully and therefore return true.
--log-backtrace-at traceLocation     默认值：:0--log-backtrace-at <a string in the form 'file:N'>     Default: :0
- -当日志机制执行到'文件 :N'时，生成堆栈跟踪。 -

when logging hits line file:N, emit a stack trace
--log-dir string
- -如果为非空，则在此目录中写入日志文件。 -

If non-empty, write log files in this directory
--log-file string
- -如果为非空，使用此值作为日志文件。 -

If non-empty, use this log file
--log-file-max-size uint     默认值：1800--log-file-max-size uint     Default: 1800
- -定义日志文件可以增长到的最大大小。单位为兆字节。 -如果值为 0，则最大文件大小为无限制。 -

Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.
--log-flush-frequency duration     默认值：5s--log-flush-frequency duration     Default: 5s
- -两次日志刷新之间的最大秒数 -

Maximum number of seconds between log flushes
--logging-format string     默认值："text"--logging-format string     Default: "text"
- -设置日志格式。允许的格式："json"，"json"。
-非默认格式不支持以下标志：--add-dir-header、--alsologtostderr、--log-backtrace-at、--log-dir、--log-file、--log-file-max-size、--logtostderr、--one-output、-skip-headers、-skip-log-headers、--stderrthreshold、-vmodule 和 --log-flush-frequency。
-当前非默认选择为 alpha，会随时更改而不会发出警告。 -

Sets the log format. Permitted formats: "text".
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --one-output, --skip-headers, --skip-log-headers, --stderrthreshold, --vmodule, --log-flush-frequency.
Non-default choices are currently alpha and subject to change without warning.
--logtostderr     默认值：true--logtostderr     Default: true
- -在标准错误而不是文件中输出日志记录。 -

log to standard error instead of files
--master-service-namespace string     默认值："default"--master-service-namespace string     Default: "default"
- -已废弃：应该从其中将 Kubernetes 主服务注入到 Pod 中的名字空间。 -

DEPRECATED: the namespace from which the Kubernetes master services should be injected into pods.
--max-connection-bytes-per-sec int
- -如果不为零，则将每个用户连接限制为该数（字节数/秒）。 -当前仅适用于长时间运行的请求。 -

If non-zero, throttle each user connection to this number of bytes/sec. Currently only applies to long-running requests.
--max-mutating-requests-inflight int     默认值：200--max-mutating-requests-inflight int     Default: 200
- -在给定时间内进行中变更类型请求的最大个数。 -当超过该值时，服务将拒绝所有请求。 -零表示无限制。 -

This and --max-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of mutating requests in flight, or a zero value disables the limit completely.
--max-requests-inflight int     默认值：400--max-requests-inflight int     Default: 400
- -在给定时间内进行中非变更类型请求的最大数量。 -当超过该值时，服务将拒绝所有请求。 -零表示无限制。 -

This and --max-mutating-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of non-mutating requests in flight, or a zero value disables the limit completely.
--min-request-timeout int     默认值：1800--min-request-timeout int     Default: 1800
- -可选字段，表示处理程序在请求超时前，必须保持其处于打开状态的最小秒数。 -当前只对监听（Watch）请求的处理程序有效，它基于这个值选择一个随机数作为连接超时值， -以达到分散负载的目的。 -

An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load.
--oidc-ca-file string
- -如果设置该值，将会使用 oidc-ca-file 中的机构之一对 OpenID 服务的证书进行验证， -否则将会使用主机的根 CA 对其进行验证。 -

If set, the OpenID server's certificate will be verified by one of the authorities in the oidc-ca-file, otherwise the host's root CA set will be used.
--oidc-client-id string
- -OpenID 连接客户端的要使用的客户 ID，如果设置了 oidc-issuer-url，则必须设置这个值。 -

The client ID for the OpenID Connect client, must be set if oidc-issuer-url is set.
--oidc-groups-claim string
- -如果提供该值，这个自定义 OpenID 连接声明将被用来设定用户组。 -该声明值需要是一个字符串或字符串数组。 -此标志为实验性的，请查阅身份认证相关文档进一步了解详细信息。 -

If provided, the name of a custom OpenID Connect claim for specifying user groups. The claim value is expected to be a string or array of strings. This flag is experimental, please see the authentication documentation for further details.
--oidc-groups-prefix string
- -如果提供了此值，则所有组都将以该值作为前缀，以防止与其他身份认证策略冲突。 -

If provided, all groups will be prefixed with this value to prevent conflicts with other authentication strategies.
--oidc-issuer-url string
- -OpenID 颁发者 URL，只接受 HTTPS 方案。 -如果设置该值，它将被用于验证 OIDC JSON Web Token(JWT)。 -

The URL of the OpenID issuer, only HTTPS scheme will be accepted. If set, it will be used to verify the OIDC JSON Web Token (JWT).
--oidc-required-claim <逗号分隔的 'key=value' 键值对列表>--oidc-required-claim <comma-separated 'key=value' pairs>
- -描述 ID 令牌中必需声明的键值对。 -如果设置此值，则会验证 ID 令牌中存在与该声明匹配的值。 -重复此标志以指定多个声明。 -

A key=value pair that describes a required claim in the ID Token. If set, the claim is verified to be present in the ID Token with a matching value. Repeat this flag to specify multiple claims.
--oidc-signing-algs strings     默认值：RS256--oidc-signing-algs strings     Default: "RS256"
- -允许的 JOSE 非对称签名算法的逗号分隔列表。 -若 JWT 所带的 "alg" 标头值不在列表中，则该 JWT 将被拒绝。 -取值依据 RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1 定义。 -

Comma-separated list of allowed JOSE asymmetric signing algorithms. JWTs with a 'alg' header value not in this list will be rejected. Values are defined by RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.
--oidc-username-claim string     默认值："sub"--oidc-username-claim string     Default: "sub"
- -要用作用户名的 OpenID 声明。 -请注意，除默认声明（"sub"）以外的其他声明不能保证是唯一且不可变的。 -此标志是实验性的，请参阅身份认证文档以获取更多详细信息。 -

The OpenID claim to use as the user name. Note that claims other than the default ('sub') is not guaranteed to be unique and immutable. This flag is experimental, please see the authentication documentation for further details.
--oidc-username-prefix string
- -如果提供，则所有用户名都将以该值作为前缀。 -如果未提供，则除 "email" 之外的用户名声明都会添加颁发者 URL 作为前缀，以避免冲突。 -要略过添加前缀处理，请设置值为 "-"。 -

If provided, all usernames will be prefixed with this value. If not provided, username claims other than 'email' are prefixed by the issuer URL to avoid clashes. To skip any prefixing, provide the value '-'.
--one-output
- -此标志为真时，日志只会被写入到其原生的严重性级别中（而不是同时写到所有较低 -严重性级别中）。 -

If true, only write logs to their native severity level (vs also writing to each lower severity level)
--permit-address-sharing     默认值：false--permit-address-sharing

- -若此标志为 true，则使用 SO_REUSEADDR 来绑定端口。 -这样设置可以同时绑定到用通配符表示的类似 0.0.0.0 这种 IP 地址， -以及特定的 IP 地址。也可以避免等待内核释放 TIME_WAIT 状态的套接字。 -

If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like 0.0.0.0 and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false]
--permit-port-sharing     默认值：false--permit-port-sharing
- -如果为 true，则在绑定端口时将使用 SO_REUSEPORT， -这样多个实例可以绑定到同一地址和端口上。 -

If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false]
--profiling     默认值：true--profiling     Default: true
- -通过 Web 接口 host:port/debug/pprof/ 启用性能分析。 -

Enable profiling via web interface host:port/debug/pprof/
--proxy-client-cert-file string
- -当必须调用外部程序以处理请求时，用于证明聚合器或者 kube-apiserver 的身份的客户端证书。 -包括代理转发到用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 -Kubernetes 期望此证书包含来自于 --requestheader-client-ca-file 标志中所给 CA 的签名。 -该 CA 在 kube-system 命名空间的 "extension-apiserver-authentication" ConfigMap 中公开。 -从 kube-aggregator 收到调用的组件应该使用该 CA 进行各自的双向 TLS 验证。 -

Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components receiving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
--proxy-client-key-file string
- -当必须调用外部程序来处理请求时，用来证明聚合器或者 kube-apiserver 的身份的客户端私钥。 -这包括代理转发给用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 -

Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.
--request-timeout duration     默认值：1m0s--request-timeout duration     Default: 1m0s
- -可选字段，指示处理程序在超时之前必须保持打开请求的持续时间。 -这是请求的默认请求超时，但对于特定类型的请求，可能会被 ---min-request-timeout等标志覆盖。 -

An optional field indicating the duration a handler must keep a request open before timing it out. This is the default request timeout for requests but may be overridden by flags such as --min-request-timeout for specific types of requests.
--requestheader-allowed-names strings
- -此值为客户端证书通用名称（Common Name）的列表；表中所列的表项可以用来提供用户名， -方式是使用 --requestheader-username-headers 所指定的头部。 -如果为空，能够通过 --requestheader-client-ca-file 中机构 -认证的客户端证书都是被允许的。 -

List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string
- -在信任请求头中以 --requestheader-username-headers 指示的用户名之前， -用于验证接入请求中客户端证书的根证书包。 -警告：一般不要假定传入请求已被授权。 -

Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.
--requestheader-extra-headers-prefix strings
- -用于查验请求头部的前缀列表。建议使用 X-Remote-Extra-。 -

List of request header prefixes to inspect. X-Remote-Extra- is suggested.
--requestheader-group-headers strings
- -用于查验用户组的请求头部列表。建议使用 X-Remote-Group。 -

List of request headers to inspect for groups. X-Remote-Group is suggested.
--requestheader-username-headers strings
- -用于查验用户名的请求头头列表。建议使用 X-Remote-User。 -

List of request headers to inspect for usernames. X-Remote-User is common.
--runtime-config <逗号分隔的 'key=value' 对列表>--runtime-config <comma-separated 'key=value' pairs>
- -一组启用或禁用内置 API 的键值对。支持的选项包括： -
v1=true|false（针对核心 API 组） -
<group>/<version>=true|false（针对特定 API 组和版本，例如：apps/v1=true） -
api/all=true|false 控制所有 API 版本 -
api/ga=true|false 控制所有 v[0-9]+ API 版本 -
api/beta=true|false 控制所有 v[0-9]+beta[0-9]+ API 版本 -
api/alpha=true|false 控制所有 v[0-9]+alpha[0-9]+ API 版本 -
api/legacy 已弃用，并将在以后的版本中删除 -

A set of key=value pairs that enable or disable built-in APIs. Supported options are:
v1=true|false for the core API group
<group>/<version>=true|false for a specific API group and version (e.g. apps/v1=true)
api/all=true|false controls all API versions
api/ga=true|false controls all API versions of the form v[0-9]+
api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+
api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+
api/legacy is deprecated, and will be removed in a future version
--secure-port int     默认值：6443--secure-port int     Default: 6443
- -带身份验证和鉴权机制的 HTTPS 服务端口。 -不能用 0 关闭。 -

The port on which to serve HTTPS with authentication and authorization. It cannot be switched off with 0.
--service-account-extend-token-expiration     默认值：true--service-account-extend-token-expiration     Default: true
- -在生成令牌时，启用投射服务帐户到期时间扩展， -这有助于从旧版令牌安全地过渡到绑定的服务帐户令牌功能。 -如果启用此标志，则准入插件注入的令牌的过期时间将延长至 1 年，以防止过渡期间发生意外故障， -并忽略 service-account-max-token-expiration 的值。 -

Turns on projected service account expiration extension during token generation, which helps safe transition from legacy token to bound service account token feature. If this flag is enabled, admission injected tokens would be extended up to 1 year to prevent unexpected failure during transition, ignoring value of service-account-max-token-expiration.
--service-account-issuer string--service-account-issuer strings
- -服务帐号令牌颁发者的标识符。 -颁发者将在已办法令牌的 "iss" 声明中检查此标识符。 -此值为字符串或 URI。 -如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI，则即使特性门控设置为 true， -ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 -强烈建议该值符合 OpenID 规范：https://openid.net/specs/openid-connect-discovery-1_0.html。 -实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 -还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration -处提供 OpenID 发现文档。 -

Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted.
--service-account-jwks-uri string
- -覆盖 /.well-known/openid-configuration 提供的发现文档中 JSON Web 密钥集的 URI。 -如果发现文档和密钥集是通过 API 服务器外部 -（而非自动检测到或被外部主机名覆盖）之外的 URL 提供给依赖方的，则此标志很有用。 -仅在启用 ServiceAccountIssuerDiscovery 特性门控的情况下有效。 -

Overrides the URI for the JSON Web Key Set in the discovery doc served at /.well-known/openid-configuration. This flag is useful if the discovery docand key set are served to relying parties from a URL other than the API server's external (as auto-detected or overridden with external-hostname). Only valid if the ServiceAccountIssuerDiscovery feature gate is enabled.
--service-account-key-file strings
- -包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。 -指定的文件可以包含多个键，并且可以使用不同的文件多次指定标志。 -如果未指定，则使用 --tls-private-key-file。 -提供 --service-account-signing-key 时必须指定。 -

File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided
--service-account-lookup     默认值：true--service-account-lookup     Default: true
- -如果为 true，则在身份认证时验证 etcd 中是否存在 ServiceAccount 令牌。 -

If true, validate ServiceAccount tokens exist in etcd as part of authentication.
--service-account-max-token-expiration duration
- -服务帐户令牌发布者创建的令牌的最长有效期。 -如果请求有效期大于此值的有效令牌请求，将使用此值的有效期颁发令牌。 -

The maximum validity duration of a token created by the service account token issuer. If an otherwise valid TokenRequest with a validity duration larger than this value is requested, a token will be issued with a validity duration of this value.
--service-account-signing-key-file string
- -包含服务帐户令牌颁发者当前私钥的文件的路径。 -颁发者将使用此私钥签署所颁发的 ID 令牌。 -

Path to the file that contains the current private key of the service account token issuer. The issuer will sign issued ID tokens with this private key.
--service-cluster-ip-range string
- -CIDR 表示的 IP 范围用来为服务分配集群 IP。 -此地址不得与指定给节点或 Pod 的任何 IP 范围重叠。 -

A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes or pods. Max of two dual-stack CIDRs is allowed.
--service-node-port-range <形式为 'N1-N2' 的字符串>     默认值：30000-32767--service-node-port-range <a string in the form 'N1-N2'>     Default: 30000-32767
- -保留给具有 NodePort 可见性的服务的端口范围。 -例如："30000-32767"。范围的两端都包括在内。 -

A port range to reserve for services with NodePort visibility. Example: '30000-32767'. Inclusive at both ends of the range.
--show-hidden-metrics-for-version string
- -你要显示隐藏指标的先前版本。仅先前的次要版本有意义，不允许其他值。 -格式为 <major>.<minor>，例如："1.16"。 -这种格式的目的是确保你有机会注意到下一个版本是否隐藏了其他指标， -而不是在此之后将它们从发行版中永久删除时感到惊讶。 -

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.
--shutdown-delay-duration duration
- -延迟终止时间。在此期间，服务器将继续正常处理请求。 -端点 /healthz 和 /livez 将返回成功，但是 /readyz 立即返回失败。 -在此延迟过去之后，将开始正常终止。 -这可用于允许负载平衡器停止向该服务器发送流量。 -

Time to delay the termination. During that time the server keeps serving requests normally. The endpoints /healthz and /livez will return success, but /readyz immediately returns failure. Graceful termination starts after this delay has elapsed. This can be used to allow load balancer to stop sending traffic to this server.
--skip-headers
- -如果为 true，日志消息中避免标题前缀。 -

If true, avoid header prefixes in the log messages
--skip-log-headers
- -如果为 true，则在打开日志文件时避免标题。 -

If true, avoid headers when opening log files
--stderrthreshold int     默认值：2--stderrthreshold int     Default: 2
- -将达到或超过此阈值的日志写到标准错误输出 -

logs at or above this threshold go to stderr
--storage-backend string
- -持久化存储后端。选项："etcd3"（默认）。 -

The storage backend for persistence. Options: 'etcd3' (default).
--storage-media-type string     默认值："application/vnd.kubernetes.protobuf"--storage-media-type string     Default: "application/vnd.kubernetes.protobuf"
- -用于在存储中存储对象的媒体类型。 -某些资源或存储后端可能仅支持特定的媒体类型，并且将忽略此设置。 -

The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting.
--strict-transport-security-directives strings

- -为 HSTS 所设置的指令列表，用逗号分隔。 -如果此列表为空，则不会添加 HSTS 指令。 -例如： 'max-age=31536000,includeSubDomains,preload' -

List of directives for HSTS, comma separated. If this list is empty, then HSTS directives will not be added. Example: 'max-age=31536000,includeSubDomains,preload'
--tls-cert-file string
- -包含用于 HTTPS 的默认 x509 证书的文件。（CA 证书（如果有）在服务器证书之后并置）。 -如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 ---tls-private-key-file， -为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 -

File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.
--tls-cipher-suites strings
- -服务器的密码套件的列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 -
首选值： -TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、 TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384. -不安全的值有： -TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA。 -

Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
--tls-min-version string
- -支持的最低 TLS 版本。可能的值：VersionTLS10，VersionTLS11，VersionTLS12，VersionTLS13 -

Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
--tls-private-key-file string
- -包含匹配 --tls-cert-file 的 x509 证书私钥的文件。 -

File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key string     默认值： []--tls-sni-cert-key string
- -一对 x509 证书和私钥文件路径，（可选）后缀为全限定域名的域名模式列表，可以使用带有通配符的前缀。 -域模式也允许使用 IP 地址，但仅当 apiserver 对客户端请求的IP地址具有可见性时，才应使用 IP。 -如果未提供域模式，则提取证书的名称。 -非通配符匹配优先于通配符匹配，显式域模式优先于提取出的名称。 -对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。 -示例："example.crt,example.key" 或 "foo.crt,foo.key:\*.foo.com,foo.com"。 -

A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".
--token-auth-file string
- -如果设置该值，这个文件将被用于通过令牌认证来保护 API 服务的安全端口。 -

If set, the file that will be used to secure the secure port of the API server via token authentication.

--tracing-config-file string

File with apiserver tracing configuration.
-v, --v int
- -日志级别详细程度的数字。 -

number for the log level verbosity
--version version[=true]
- -打印版本信息并退出 -

Print version information and quit
--vmodule <用逗号分隔的多个 'pattern=N' 配置字符串>--vmodule <comma-separated 'pattern=N' settings>
- -以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录。 -

comma-separated list of pattern=N settings for file-filtered logging
--watch-cache     默认值：true--watch-cache     Default: true
- -在 API 服务器中启用监视缓存。 -

Enable watch caching in the apiserver
--watch-cache-sizes strings
- -某些资源（Pods、Nodes 等）的监视缓存大小设置，以逗号分隔。 -每个资源对应的设置格式：resource[.group]#size，其中 -resource 为小写复数（无版本）， -对于 apiVersion v1（旧版核心 API）的资源要省略 group， -对其它资源要给出 group；size 为一个数字。 -启用 watch-cache 时，此功能生效。 -某些资源（replicationcontrollers、endpoints、 -nodes、pods、services、 -apiservices.apiregistration.k8s.io） -具有通过启发式设置的系统默认值，其他资源默认为 -default-watch-cache-size。 -

Watch cache size settings for some resources (pods, nodes, etc.), comma separated. The individual setting format: resource[.group]#size, where resource is lowercase plural (no version), group is omitted for resources of apiVersion v1 (the legacy core API) and included for others, and size is a number. It takes effect when watch-cache is enabled. Some resources (replicationcontrollers, endpoints, nodes, pods, services, apiservices.apiregistration.k8s.io) have system defaults set by heuristics, others default to default-watch-cache-size
+ + From 8b0c67d651be1348d94bc94dc2859894c7a3db96 Mon Sep 17 00:00:00 2001 From: ptux Date: Tue, 28 Dec 2021 10:29:00 +0900 Subject: [PATCH 029/145] fix --- .../ja/docs/tasks/debug-application-cluster/audit.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 6ed9fd04d8..5eb18ca231 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -1,15 +1,17 @@ --- content_type: concept +reviewers: +- ptux title: 監査 --- -Kubernetesの監査はクラスタ内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 -クラスタはユーザー、Kubernetes APIを使用するアプリケーション、 +Kubernetesの監査はクラスター内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 +クラスターはユーザー、Kubernetes APIを使用するアプリケーション、 およびコントロールプレーン自体によって生成されたアクティビティなどを監査します。 -監査により、クラスタ管理者は以下の質問に答えることができます: +監査により、クラスター管理者は以下の質問に答えることができます: - 何が起きたのか？ - いつ起こったのか？ @@ -132,7 +134,7 @@ kube-apiserverには2つのバックエンドが用意されています。 - `audit-log-maxbackup`は、保持する監査ログファイルの最大数を定義します。 - `--audit-log-maxsize` は、監査ログファイルがローテーションされるまでの最大サイズをメガバイト単位で定義します。 -クラスタのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 +クラスターのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 例えば: ```shell --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ @@ -229,7 +231,7 @@ logバックエンドとwebhookバックエンドは、ログに記録される - `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 -デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスタ管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 +デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 ## {{% heading "whatsnext" %}} From ad11be44494e6e860fba10207b966cb622b3a5a3 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:29:46 +0900 Subject: [PATCH 030/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 5eb18ca231..92f004f587 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -23,7 +23,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ -監査記録は、そのライフサイクルを[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 +監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 From 1e498bf0313d1ba491fb543145573a5b5f14b6cf Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:29:52 +0900 Subject: [PATCH 031/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 92f004f587..335750634e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -205,7 +205,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 - `--audit-webhook-batch-throttle-burst`は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 -## パラメータチューニング +## パラメーターチューニング パラメータは、APIサーバーの負荷に合わせて設定してください。 From fc62908083dc1550915c9093cf51e19a58447a4c Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:29:58 +0900 Subject: [PATCH 032/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 335750634e..c3c5d3b11e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -207,7 +207,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 ## パラメーターチューニング -パラメータは、APIサーバーの負荷に合わせて設定してください。 +パラメーターは、APIサーバーの負荷に合わせて設定してください。 例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 1 つのバッチに最大 100 個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 From f08434993de125571ce16c6f6a890092596796d4 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:30:06 +0900 Subject: [PATCH 033/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index c3c5d3b11e..64ee45d680 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -210,7 +210,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 パラメーターは、APIサーバーの負荷に合わせて設定してください。 例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 -1 つのバッチに最大 100 個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 +1つのバッチに最大100個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファサイズを設定する必要があります。 10バッチ、または1000イベントとなります。 From 5091e15ec8706a0aaefe02c7e0825f205b63ac42 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:30:13 +0900 Subject: [PATCH 034/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 64ee45d680..94323fee41 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -211,7 +211,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 1つのバッチに最大100個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 -バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファサイズを設定する必要があります。 +バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファーサイズを設定する必要があります。 10バッチ、または1000イベントとなります。 From 683af6800e5b12f046aa4df7f9359a86e145dc1f Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:30:37 +0900 Subject: [PATCH 035/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 94323fee41..6085f1a029 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -24,7 +24,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ 監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 -各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 +各リクエストの実行の各段階で、監査イベントが生成されます。 ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 From 08f17252ff030a7a5749967dc8e9aa06cac614a5 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:30:49 +0900 Subject: [PATCH 036/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 6085f1a029..67b75abf8b 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -25,7 +25,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ 監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 各リクエストの実行の各段階で、監査イベントが生成されます。 -ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 +ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 各リクエストは関連する _stage_ で記録されます。 From 518bfe85e16b40b13a5de5ae3fff9bd79abba5d0 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:31:01 +0900 Subject: [PATCH 037/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 67b75abf8b..933ed20dfc 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -34,7 +34,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ - `RequestReceived` - 監査ハンドラーがリクエストを受信すると同時に生成されるイベントのステージ。 つまり、ハンドラーチェーンに委譲される前に生成されるイベントのステージです。 - `ResponseStarted` - レスポンスヘッダーが送信された後、レスポンスボディが送信される前のステージです。 - このステージは長時間実行されるリクエスト（watchなど）でのみ発生します。 + このステージは長時間実行されるリクエスト(watchなど)でのみ発生します。 - `ResponseComplete` - レスポンスボディの送信が完了して、それ以上のバイトは送信されません。 - `Panic` - パニックが起きたときに発生するイベント。 From 940dbeddd7016a5d6782495927363000d9bbe60d Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:31:33 +0900 Subject: [PATCH 038/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 933ed20dfc..d0c2dc4e61 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -42,7 +42,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ [Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)APIオブジェクトとは異なります。 {{< /note >}} -監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリ消費量が増加します。 +監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリー消費量が増加します。 メモリの消費量は、監査ログ機能の設定によって異なります。 ## Audit policy From ca6b01b7c1eb97ea6096b339dca2f4a0db055b4d Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:31:47 +0900 Subject: [PATCH 039/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index d0c2dc4e61..3bfd3a119e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -43,7 +43,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ {{< /note >}} 監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリー消費量が増加します。 -メモリの消費量は、監査ログ機能の設定によって異なります。 +メモリーの消費量は、監査ログ機能の設定によって異なります。 ## Audit policy From dc60343888718ab3e3f01e701feafc0e1ce62ef2 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:31:59 +0900 Subject: [PATCH 040/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 3bfd3a119e..b500a436c9 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -48,7 +48,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ ## Audit policy 監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 -監査ポリシーのオブジェクト構造は、[audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 +監査ポリシーのオブジェクト構造は、[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 イベントが処理されると、そのイベントは順番にルールのリストと比較されます。 最初のマッチングルールは、イベントの監査レベルを設定します。 From 464efc69f7321fc2efa10e01b53e471d5017a584 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:32:12 +0900 Subject: [PATCH 041/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index b500a436c9..9bbdbaae8d 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -45,7 +45,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ 監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリー消費量が増加します。 メモリーの消費量は、監査ログ機能の設定によって異なります。 -## Audit policy +## 監査ポリシー 監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 監査ポリシーのオブジェクト構造は、[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 From 887ee7c11dcd1541affb5dd5f290f730da0f862c Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:32:22 +0900 Subject: [PATCH 042/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 9bbdbaae8d..6db2e9eae6 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -56,7 +56,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ 定義されている監査レベルは: - `None` - ルールに一致するイベントを記録しません。 -- `Metadata` - lリクエストのメタデータ（リクエストしたユーザー、タイムスタンプ、リソース、動作など）を記録しますが、リクエストやレスポンスのボディは記録しません。 +- `Metadata` - リクエストのメタデータ(リクエストしたユーザー、タイムスタンプ、リソース、動作など)を記録しますが、リクエストやレスポンスのボディは記録しません。 - `Request` - ログイベントのメタデータとリクエストボディは表示されますが、レスポンスボディは表示されません。 これは非リソースリクエストには適用されません。 - `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 From 6836db14a133fa48438d537e5e97737805807d7f Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:32:33 +0900 Subject: [PATCH 043/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 6db2e9eae6..d2736240ce 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -72,7 +72,7 @@ A policy with no (0) rules is treated as illegal. 監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 ルールがない(0)ポリシーは不当なものとして扱われます。 -以下は監査ポリシーファイルの例: +以下は監査ポリシーファイルの例です: {{< codenew file="audit/audit-policy.yaml" >}} From 463a2ae5adc619321c7e644ad277e8414c20b582 Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:32:46 +0900 Subject: [PATCH 044/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index d2736240ce..ff4be2168f 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -88,7 +88,7 @@ rules: 独自の監査プロファイルを作成する場合は、Google Container-Optimized OSの監査プロファイルを出発点として使用できます。 監査ポリシーファイルを生成する[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)スクリプトを確認することができます。 -スクリプトを直視することで、監査ポリシーファイルのほとんどを見ることができます。 +スクリプトを直接見ることで、監査ポリシーファイルのほとんどを見ることができます。 また、定義されているフィールドの詳細については、[Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)を参照できます。 From ea1368d2713abb9249944896f66158a17f1d724a Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:32:54 +0900 Subject: [PATCH 045/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index ff4be2168f..ea4d04d588 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -180,7 +180,7 @@ Webhook監査バックエンドを設定するには、以下のkube-apiserver - `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 それ以降のリクエストは、指数関数的なバックオフで再試行されます。 -Webhookの設定ファイルは、kubeconfig 形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 +Webhookの設定ファイルは、kubeconfig形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 ## イベントバッチ {#batching} From edcac816d73cd9d53ee954c4e7cb4c2151721c4e Mon Sep 17 00:00:00 2001 From: Wang Date: Tue, 28 Dec 2021 10:33:04 +0900 Subject: [PATCH 046/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index ea4d04d588..325beb490d 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -168,7 +168,7 @@ volumeMounts: ``` -### Webhook バックエンド +### Webhookバックエンド Webhook監査バックエンドは、監査イベントをリモートのWeb APIに送信しますが、 これは認証手段を含むKubernetes APIの形式であると想定されます。 From b645bc7890641304163e5e672baf4410fbb264f4 Mon Sep 17 00:00:00 2001 From: ptux Date: Tue, 28 Dec 2021 10:34:43 +0900 Subject: [PATCH 047/145] remove the En content --- content/ja/docs/tasks/debug-application-cluster/audit.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 325beb490d..d71dcb76a6 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -62,11 +62,6 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ - `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 非リソースリクエストには適用されません。 -You can pass a file with the policy to `kube-apiserver` -using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. -Note that the `rules` field __must__ be provided in the audit policy file. -A policy with no (0) rules is treated as illegal. - `audit-policy-file`フラグを使って、ポリシーを記述したファイルを `kube-apiserver`に渡すことができます。 このフラグが省略された場合イベントは記録されません。 監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 From 8fcbeb9b9ae0c76efa841ce81fc19342baa44a5a Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:33:08 +0900 Subject: [PATCH 048/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 5d748eeba1..179177f732 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -105,7 +105,7 @@ kubectl create secret generic test-secret --from-literal='username=my-app' --fro kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml ``` -1. Podがランニング状態にあるのを確認する: +1. Podの`STATUS`が`Running`であるのを確認する: ```shell kubectl get pod secret-test-pod From 1c9b990b4aca56c92c67320f3c8460f88232a6ae Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:33:21 +0900 Subject: [PATCH 049/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 179177f732..203a703a04 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -15,7 +15,7 @@ min-kubernetes-server-version: v1.6 ### 機密データをbase64でエンコードする -ユーザー名 `my-app` とパスワード `39528$vdg7Jb` の2つの機密データが必要だとします。 +ユーザー名`my-app`とパスワード`39528$vdg7Jb`の2つの機密データが必要だとします。 まず、base64エンコーディングツールを使って、ユーザ名とパスワードをbase64表現に変換します。 ここでは、手軽に入手できるbase64プログラムを使った例を紹介します: From 481d62f9571007e0f9d062287d6b4e7cb08946bf Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:33:34 +0900 Subject: [PATCH 050/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 203a703a04..6c2afe0259 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -90,7 +90,7 @@ base64エンコードの手順を省略したい場合は、`kubectl create secr kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' ``` -先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、`kubectl create secret` の方が便利です。 +先ほどの詳細なアプローチでは 各ステップを明示的に実行し、何が起こっているかを示していますが、`kubectl create secret`の方が便利です。 ## Volumeにある機密情報をアクセスするPodを作成する From 20ff4dba3b500ff9db08b7ade19a5edf05f2c49c Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:34:05 +0900 Subject: [PATCH 051/145] Update content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../inject-data-application/distribute-credentials-secure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md index 6c2afe0259..9cc49e3924 100644 --- a/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ja/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -24,7 +24,7 @@ echo -n 'my-app' | base64 echo -n '39528$vdg7Jb' | base64 ``` -出力結果によると、ユーザ名のbase64表現は `bXktYXBw`で、パスワードのbase64表現は `Mzk1MjgkdmRnN0pi` です。 +出力結果によると、ユーザ名のbase64表現は`bXktYXBw`で、パスワードのbase64表現は`Mzk1MjgkdmRnN0pi`です。 {{< caution >}} OSから信頼されているローカルツールを使用することで、外部ツールのセキュリティリスクを低減することができます。 From 6b6f2aa76265954931daa8e5881e07bfd7b86186 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:34:58 +0900 Subject: [PATCH 052/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 947a1b3a14..de025678d0 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -12,7 +12,7 @@ content_type: task `crictl`はCRI互換のコンテナランタイム用のコマンドラインインターフェイスです。 -これを使って、Kubernetes ノード上のコンテナランタイムやアプリケーションの検査やデバッグを行うことができます。 +これを使って、Kubernetesノード上のコンテナランタイムやアプリケーションの検査やデバッグを行うことができます。 `crictl`とそのソースは[cri-tools](https://github.com/kubernetes-sigs/cri-tools)リポジトリにホストされています。 ## {{% heading "prerequisites" %}} From 80a4405e778b5b429ccd5ecc12282657cb611bf7 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:06 +0900 Subject: [PATCH 053/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index de025678d0..930de9756a 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -13,7 +13,7 @@ content_type: task `crictl`はCRI互換のコンテナランタイム用のコマンドラインインターフェイスです。 これを使って、Kubernetesノード上のコンテナランタイムやアプリケーションの検査やデバッグを行うことができます。 -`crictl`とそのソースは[cri-tools](https://github.com/kubernetes-sigs/cri-tools)リポジトリにホストされています。 +`crictl`とそのソースコードは[cri-tools](https://github.com/kubernetes-sigs/cri-tools)リポジトリにホストされています。 ## {{% heading "prerequisites" %}} From c0b89323cc6cd1fe28aedcfaca3f644d0aff24ed Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:15 +0900 Subject: [PATCH 054/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 930de9756a..51d557ac5b 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -18,7 +18,7 @@ content_type: task ## {{% heading "prerequisites" %}} -`crictl`にはCRIランタイムを搭載した Linux が必要です。 +`crictl`にはCRIランタイムを搭載したLinuxが必要です。 From 3b64cd570353cd7118d00d50f5bf363b9537c66e Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:22 +0900 Subject: [PATCH 055/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 51d557ac5b..50c0624470 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -26,7 +26,7 @@ content_type: task ## crictlのインストール -cri-tools [release page](https://github.com/kubernetes-sigs/cri-tools/releases)から、いくつかの異なるアーキテクチャ用の圧縮アーカイブ`crictl`をダウンロードできます。 +cri-toolsの[リリースページ](https://github.com/kubernetes-sigs/cri-tools/releases)から、いくつかの異なるアーキテクチャ用の圧縮アーカイブ`crictl`をダウンロードできます。 お使いのKubernetesのバージョンに対応するバージョンをダウンロードしてください。 それを解凍してシステムパス上の`/usr/local/bin/`などの場所に移動します。 From b88e373e01ecd533cca5f4802ca0e771c28bc2ca Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:29 +0900 Subject: [PATCH 056/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 50c0624470..be96213a1e 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -310,7 +310,7 @@ crictl logs --tail=1 87d3992f84f74 crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json ``` -4. すべてのコンテナをリストアップし、新しく作成されたコンテナのステートが`Created`に設定されていることを確認します: +4. すべてのコンテナをリストアップし、新しく作成されたコンテナの状態が`Created`に設定されていることを確認します: ```shell crictl ps -a From 0d9ed1dc00bcbff1be5e085d92ef58c10b0dab94 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:38 +0900 Subject: [PATCH 057/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index be96213a1e..e87fe32fac 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -368,7 +368,7 @@ CRICTLの出力形式はDocker CLIと似ていますが、いくつかのCLIで {{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} docker cli | crictl | 説明 | サポートされていない機能 -- | -- | -- | -- -`attach` | `attach` | ランニングコンテナにアタッチ | `--detach-keys`, `--sig-proxy` +`attach` | `attach` | 実行中のコンテナにアタッチ | `--detach-keys`, `--sig-proxy` `exec` | `exec` | ランニングコンテナにコマンドの実行 | `--privileged`, `--user`, `--detach-keys` `images` | `images` | イメージのリストアップ |   `info` | `info` | システム全体の情報の表示 |   From b7c7c6cd66bc0f3aff5d736f2b5a16280e705a71 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:35:58 +0900 Subject: [PATCH 058/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index e87fe32fac..0a005424ea 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -369,7 +369,7 @@ CRICTLの出力形式はDocker CLIと似ていますが、いくつかのCLIで docker cli | crictl | 説明 | サポートされていない機能 -- | -- | -- | -- `attach` | `attach` | 実行中のコンテナにアタッチ | `--detach-keys`, `--sig-proxy` -`exec` | `exec` | ランニングコンテナにコマンドの実行 | `--privileged`, `--user`, `--detach-keys` +`exec` | `exec` | 実行中のコンテナでコマンドの実行 | `--privileged`, `--user`, `--detach-keys` `images` | `images` | イメージのリストアップ |   `info` | `info` | システム全体の情報の表示 |   `inspect` | `inspect`, `inspecti` | コンテナ、イメージ、タスクの低レベルの情報を返します |   From 3a2047889ea0b4cda86d156d0c7429b1c6f2a073 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:36:04 +0900 Subject: [PATCH 059/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 0a005424ea..cf32f9f5e3 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -376,7 +376,7 @@ docker cli | crictl | 説明 | サポートされていない機能 `logs` | `logs` | コンテナのログを取得します | `--details` `ps` | `ps` | コンテナのリストアップ |   `stats` | `stats` | コンテナのリソース使用状況をライブで表示 | Column: NET/BLOCK I/O, PIDs -`version` | `version` | ランタイム（Docker、ContainerD、その他）のバージョン情報を表示します |   +`version` | `version` | ランタイム(Docker、ContainerD、その他)のバージョン情報を表示します |   {{< /table >}} ### 変更を行います From eb47f5b6c073af66a573d0a1c16ecd7e9bbeae3e Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:36:15 +0900 Subject: [PATCH 060/145] Update content/ja/docs/tasks/debug-application-cluster/crictl.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index cf32f9f5e3..85fe540dea 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -386,7 +386,7 @@ docker cli | crictl | 説明 | サポートされていない機能 -- | -- | -- | -- `create` | `create` | 新しいコンテナを作成します |   `kill` | `stop` (timeout = 0) | 1つ以上の実行中のコンテナを停止します | `--signal` -`pull` | `pull` | レジストリからイメージやリポジトリをプルします | `--all-tags`, `--disable-content-trust` +`pull` | `pull` | レジストリーからイメージやリポジトリをプルします | `--all-tags`, `--disable-content-trust` `rm` | `rm` | 1つまたは複数のコンテナを削除します |   `rmi` | `rmi` | 1つまたは複数のイメージを削除します |   `run` | `run` | 新しいコンテナでコマンドを実行 |   From 00a454f43d941e3b3b5a3618d34da08a99ff9f08 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:37:15 +0900 Subject: [PATCH 061/145] Update crictl.md --- content/ja/docs/tasks/debug-application-cluster/crictl.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/crictl.md b/content/ja/docs/tasks/debug-application-cluster/crictl.md index 85fe540dea..3e3adbc7c3 100644 --- a/content/ja/docs/tasks/debug-application-cluster/crictl.md +++ b/content/ja/docs/tasks/debug-application-cluster/crictl.md @@ -1,6 +1,4 @@ --- -reviewers: -- ptux title: crictlによるKubernetesノードのデバッグ content_type: task --- From a85d4b8bec73c33d518ed66fd667dc6477dcf356 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:42:21 +0900 Subject: [PATCH 062/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index d71dcb76a6..2ff39f4ea2 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -17,7 +17,7 @@ Kubernetesの監査はクラスター内の一連の行動を記録するセキ - いつ起こったのか？ - 誰がそれを始めたのか？ - 何のために起こったのか？ - - それはどこで観察されましたか？ + - それはどこで観察されたのか？ - それはどこから始まったのか？ - それはどこへ向かっていたのか？ From b42062ad97ae3a867fe3ae9dc5b595852b2334bc Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:42:29 +0900 Subject: [PATCH 063/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: nasa9084 --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 2ff39f4ea2..076ce6cc89 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -171,7 +171,7 @@ Webhook監査バックエンドは、監査イベントをリモートのWeb API Webhook監査バックエンドを設定するには、以下のkube-apiserverフラグを使用します。 - `--audit-webhook-config-file` は、Webhookの設定ファイルのパスを指定します。 - webhookの設定は、事実上特化した [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters) です。 + webhookの設定は、事実上特化した[kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)です。 - `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 それ以降のリクエストは、指数関数的なバックオフで再試行されます。 From 6f8e01f3fd2a8ca31c5d757191016c99ca1beb0b Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:42:46 +0900 Subject: [PATCH 064/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 076ce6cc89..c4d31ccf11 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -213,7 +213,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 しかし、ほとんどの場合デフォルトのパラメーターで十分であり、手動で設定する必要はありません。 kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 -- `apiserver_audit_event_total` メトリックには、エクスポートされた監査イベントの合計数が含まれます。 +- `apiserver_audit_event_total`メトリックには、エクスポートされた監査イベントの合計数が含まれます。 - `apiserver_audit_error_total` メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 ### ログエントリー・トランケーション {#truncate} From 8aa713d39db38e27ee35beadcd69e9ae706b07d8 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:42:53 +0900 Subject: [PATCH 065/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index c4d31ccf11..a0e14addda 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -214,7 +214,7 @@ webhookを例に、利用可能なフラグの一覧を示します。 kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 - `apiserver_audit_event_total`メトリックには、エクスポートされた監査イベントの合計数が含まれます。 -- `apiserver_audit_error_total` メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 +- `apiserver_audit_error_total`メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 ### ログエントリー・トランケーション {#truncate} From 4bfe55f6c5773e861beaff13bb9641ed81895600 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:43:00 +0900 Subject: [PATCH 066/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index a0e14addda..9df94e760a 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -222,7 +222,7 @@ logバックエンドとwebhookバックエンドは、ログに記録される 例として、logバックエンドで利用可能なフラグの一覧を以下に示します -- `audit-log-truncate-enabled` イベントとバッチの切り捨てを有効にするかどうかです。 +- `audit-log-truncate-enabled`イベントとバッチの切り捨てを有効にするかどうかです。 - `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 From e3837be65cda69ca15d0c47e439490de8450b71f Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:43:07 +0900 Subject: [PATCH 067/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 9df94e760a..78c93d5999 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -223,7 +223,7 @@ logバックエンドとwebhookバックエンドは、ログに記録される 例として、logバックエンドで利用可能なフラグの一覧を以下に示します - `audit-log-truncate-enabled`イベントとバッチの切り捨てを有効にするかどうかです。 -- `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 +- `audit-log-truncate-max-batch-size`バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 From 180187a4acf42b6b443b387bc20953cda4dab668 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:43:13 +0900 Subject: [PATCH 068/145] Update content/ja/docs/tasks/debug-application-cluster/audit.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 78c93d5999..34c99acb52 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -224,7 +224,7 @@ logバックエンドとwebhookバックエンドは、ログに記録される - `audit-log-truncate-enabled`イベントとバッチの切り捨てを有効にするかどうかです。 - `audit-log-truncate-max-batch-size`バックエンドに送信されるバッチのバイト単位の最大サイズ。 -- `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 +- `audit-log-truncate-max-event-size`バックエンドに送信される監査イベントのバイト単位の最大サイズです。 デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 From 295c5139c15d5278a6928a12caec3a85c3931268 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 3 Jan 2022 08:43:52 +0900 Subject: [PATCH 069/145] Update audit.md --- content/ja/docs/tasks/debug-application-cluster/audit.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/audit.md b/content/ja/docs/tasks/debug-application-cluster/audit.md index 34c99acb52..b020b9c0b2 100644 --- a/content/ja/docs/tasks/debug-application-cluster/audit.md +++ b/content/ja/docs/tasks/debug-application-cluster/audit.md @@ -1,7 +1,5 @@ --- content_type: concept -reviewers: -- ptux title: 監査 --- From 1d56098e9a7e62677df69d49fa03b9ab58b1032a Mon Sep 17 00:00:00 2001 From: hhyasdf <552483776@qq.com> Date: Thu, 30 Dec 2021 12:10:26 +0800 Subject: [PATCH 070/145] Add Hybridnet CNI to networking.md --- content/en/docs/concepts/cluster-administration/networking.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index fb34a82d50..6b8cf74990 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -178,6 +178,10 @@ With this toolset DANM is able to provide multiple separated network interfaces, network that satisfies the Kubernetes requirements. Many people have reported success with Flannel and Kubernetes. +### Hybridnet + +[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity. + ### Jaguar [Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod. From a08460d8cdc9857c1147a13c8ad07f08cc9d5f2c Mon Sep 17 00:00:00 2001 From: howieyuen Date: Fri, 31 Dec 2021 16:04:11 +0800 Subject: [PATCH 071/145] [zh]translate content/zh/docs/tutorials/security/ns-level-pss.md --- content/zh/docs/tutorials/security/_index.md | 5 + .../docs/tutorials/security/ns-level-pss.md | 243 ++++++++++++++++++ 2 files changed, 248 insertions(+) create mode 100644 content/zh/docs/tutorials/security/_index.md create mode 100644 content/zh/docs/tutorials/security/ns-level-pss.md diff --git a/content/zh/docs/tutorials/security/_index.md b/content/zh/docs/tutorials/security/_index.md new file mode 100644 index 0000000000..0b95f9304e --- /dev/null +++ b/content/zh/docs/tutorials/security/_index.md @@ -0,0 +1,5 @@ +--- +title: "安全" +weight: 40 +--- + diff --git a/content/zh/docs/tutorials/security/ns-level-pss.md b/content/zh/docs/tutorials/security/ns-level-pss.md new file mode 100644 index 0000000000..a141edfb3a --- /dev/null +++ b/content/zh/docs/tutorials/security/ns-level-pss.md @@ -0,0 +1,243 @@ +--- +title: 在名字空间级别应用 Pod 安全标准 +content_type: tutorial +weight: 10 +--- + + + +{{% alert title="Note" %}} + +本教程仅适用于新集群。 +{{% /alert %}} + + +Pod 安全准入（PSA）在 v1.23 及更高版本默认启用， +因为它[升级到测试版（beta）](/blog/2021/12/09/pod-security-admission-beta/)。 +Pod 安全准入是在创建 Pod 时应用 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)的准入控制器。 +在本教程中，你将应用 `baseline` Pod 安全标准，每次一个名字空间。 + +你还可以在集群级别一次将 Pod 安全标准应用于多个名称空间。 +有关说明，请参阅[在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss)。 + +## {{% heading "prerequisites" %}} + + +在你的工作站中安装以下内容： + +- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + + +## 创建集群 {#create-cluster} + +2. 按照如下方式创建一个 `KinD` 集群： + + ```shell + kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 + ``` + + 输入类似于： + ``` + Creating cluster "psa-ns-level" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-ns-level" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-ns-level + + Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ + ``` + + +1. 将 kubectl 上下文设置为新集群： + ```shell + kubectl cluster-info --context kind-psa-ns-level + ``` + + 输入类似于： + ``` + Kubernetes control plane is running at https://127.0.0.1:50996 + CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +## 创建名字空间 {#create-a-namespace} + +创建一个名为 `example` 的新名字空间： + +```shell +kubectl create ns example +``` + +输出类似于： +``` +namespace/example created +``` + + +## 应用 Pod 安全标准 {#apply-pod-security-standards} + +1. 使用内置 Pod 安全准入所支持的标签在此名字空间上启用 Pod 安全标准。 + 在这一步中，我们将根据最新版本（默认值）对基线 Pod 安全标准发出警告。 + + ```shell + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/warn=baseline \ + pod-security.kubernetes.io/warn-version=latest + ``` + + +2. 可以使用标签在任何名字空间上启用多个 Pod 安全标准。 + 以下命令将强制（`enforce`） 执行基线（`baseline`）Pod 安全标准， + 但根据最新版本（默认值）对受限（`restricted`）Pod 安全标准执行警告（`warn`）和审核（`audit`）。 + + ``` + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/enforce=baseline \ + pod-security.kubernetes.io/enforce-version=latest \ + pod-security.kubernetes.io/warn=restricted \ + pod-security.kubernetes.io/warn-version=latest \ + pod-security.kubernetes.io/audit=restricted \ + pod-security.kubernetes.io/audit-version=latest + ``` + + +## 验证 Pod 安全标准 {#verify-the-pod-security-standards} + +1. 在 `example` 名字空间中创建一个最小的 pod： + + ```shell + cat < /tmp/pss/nginx-pod.yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 + EOF + ``` + + +1. 将 Pod 规约应用到集群中的 `example` 名字空间中： + ```shell + kubectl apply -n example -f /tmp/pss/nginx-pod.yaml + ``` + + 输出类似于： + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + + +3. 将 Pod 规约应用到集群中的 `default` 名字空间中： + ```shell + kubectl apply -n default -f /tmp/pss/nginx-pod.yaml + ``` + + 输入类似于： + ``` + pod/nginx created + ``` + + +以上 Pod 安全标准仅被应用到 `example` 名字空间。 +你可以在没有警告的情况下在 `default` 名字空间中创建相同的 Pod。 + + +## 清理 {#clean-up} + +运行 `kind delete cluster -name psa-ns-level` 删除创建的集群。 + +## {{% heading "whatsnext" %}} + + +- 运行一个 [shell 脚本](/examples/security/kind-with-namespace-level-baseline-pod-security.sh) + 一次执行所有前面的步骤。 + 1. 创建 KinD 集群 + 2. 创建新的名字空间 + 3. 在 `enforce` 模式下应用 `baseline` Pod 安全标准， + 同时在 `warn` 和 `audit` 模式下应用 `restricted` Pod 安全标准。 + 4. 创建一个应用以下 Pod 安全标准的新 Pod +- [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +- [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) +- [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/) \ No newline at end of file From cf8ddb9aed69574d5801ff1583affa3a46fe09cb Mon Sep 17 00:00:00 2001 From: howieyuen Date: Fri, 31 Dec 2021 16:42:43 +0800 Subject: [PATCH 072/145] [zh]translate content/zh/docs/tutorials/security/cluster-level-pss.md --- .../tutorials/security/cluster-level-pss.md | 444 ++++++++++++++++++ 1 file changed, 444 insertions(+) create mode 100644 content/zh/docs/tutorials/security/cluster-level-pss.md diff --git a/content/zh/docs/tutorials/security/cluster-level-pss.md b/content/zh/docs/tutorials/security/cluster-level-pss.md new file mode 100644 index 0000000000..0b4721c43b --- /dev/null +++ b/content/zh/docs/tutorials/security/cluster-level-pss.md @@ -0,0 +1,444 @@ +--- +title: 在集群级别应用 Pod 安全标准 +content_type: tutorial +weight: 10 +--- + + +{{% alert title="Note" %}} + +本教程仅适用于新集群。 +{{% /alert %}} + + +Pod 安全准入（PSA）在 v1.23 及更高版本默认启用， +因为它[升级到测试版（beta）](/blog/2021/12/09/pod-security-admission-beta/)。 +Pod 安全准入是在创建 Pod 时应用 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)的准入控制器。 +本教程将向你展示如何在集群级别实施 `baseline` Pod 安全标准， +该标准将标准配置应用于集群中的所有名称空间。 + +要将 Pod 安全标准应用于特定名字空间， +请参阅[在名字空间级别应用 Pod 安全标准](/zh/docs/tutorials/security/ns-level-pss)。 + +## {{% heading "prerequisites" %}} + +在你的工作站中安装以下内容： + +- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + + +## 正确选择要应用的 Pod 安全标准 {#choose-the-right-pod-security-standard-to-apply} + +[Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +允许你使用以下模式应用内置的 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/): +`enforce`、`audit` 和 `warn`。 + +要收集信息以便选择最适合你的配置的 Pod 安全标准，请执行以下操作： + + +1. 创建一个没有应用 Pod 安全标准的集群： + + ```shell + kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 + ``` + + 输出类似于： + ``` + Creating cluster "psa-wo-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-wo-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-wo-cluster-pss + + Thanks for using kind! 😊 + + ``` + + +2. 将 kubectl 上下文设置为新集群： + + ```shell + kubectl cluster-info --context kind-psa-wo-cluster-pss + ``` + + 输出类似于： + + ``` + Kubernetes control plane is running at https://127.0.0.1:61350 + CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +3. 获取集群中的名字空间列表： + + ```shell + kubectl get ns + ``` + + 输出类似于： + ``` + NAME STATUS AGE + default Active 9m30s + kube-node-lease Active 9m32s + kube-public Active 9m32s + kube-system Active 9m32s + local-path-storage Active 9m26s + ``` + + +4. 使用 `--dry-run=server` 来了解应用不同的 Pod 安全标准时会发生什么： + + 1. Privileged + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=privileged + ``` + + 输出类似于： + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + 2. Baseline + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=baseline + ``` + + 输出类似于： + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest" + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + + 3. Restricted + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=restricted + ``` + + 输出类似于： + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest" + Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + namespace/kube-system labeled + Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest" + Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile + namespace/local-path-storage labeled + ``` + + +从前面的输出中，你会注意到应用 `privileged` Pod 安全标准不会显示任何名字空间的警告。 +然而，`baseline` 和 `restricted` 标准都有警告，特别是在 `kube-system` 名字空间中。 + + +## 设置模式、版本和标准 {#set-modes-versions-and-standards} + +在本节中，你将以下 Pod 安全标准应用于最新（`latest`）版本： + +* 在 `enforce` 模式下的 `baseline` 标准。 +* `warn` 和 `audit` 模式下的 `restricted` 标准。 + + +`baseline` Pod 安全标准提供了一个方便的中间立场，能够保持豁免列表简短并防止已知的特权升级。 + +此外，为了防止 `kube-system` 中的 Pod 失败，你将免除该名字空间应用 Pod 安全标准。 + +在你自己的环境中实施 Pod 安全准入时，请考虑以下事项： + + +1. 根据应用于集群的风险状况，更严格的 Pod 安全标准（如 `restricted`）可能是更好的选择。 +2. 对 `kube-system` 名字空间进行赦免会允许 Pod 在其中以 `privileged` 模式运行。 + 对于实际使用，Kubernetes 项目强烈建议你应用严格的 RBAC 策略来限制对 `kube-system` 的访问， + 遵循最小特权原则。 +3. 创建一个配置文件，Pod 安全准入控制器可以使用该文件来实现这些 Pod 安全标准： + + ``` + mkdir -p /tmp/pss + cat < /tmp/pss/cluster-level-pss.yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: AdmissionConfiguration + plugins: + - name: PodSecurity + configuration: + apiVersion: pod-security.admission.config.k8s.io/v1beta1 + kind: PodSecurityConfiguration + defaults: + enforce: "baseline" + enforce-version: "latest" + audit: "restricted" + audit-version: "latest" + warn: "restricted" + warn-version: "latest" + exemptions: + usernames: [] + runtimeClasses: [] + namespaces: [kube-system] + EOF + ``` + + +4. 在创建集群时配置 API 服务器使用此文件： + + ``` + cat < /tmp/pss/cluster-config.yaml + kind: Cluster + apiVersion: kind.x-k8s.io/v1alpha4 + nodes: + - role: control-plane + kubeadmConfigPatches: + - | + kind: ClusterConfiguration + apiServer: + extraArgs: + admission-control-config-file: /etc/config/cluster-level-pss.yaml + extraVolumes: + - name: accf + hostPath: /etc/config + mountPath: /etc/config + readOnly: false + pathType: "DirectoryOrCreate" + extraMounts: + - hostPath: /tmp/pss + containerPath: /etc/config + # optional: if set, the mount is read-only. + # default false + readOnly: false + # optional: if set, the mount needs SELinux relabeling. + # default false + selinuxRelabel: false + # optional: set propagation mode (None, HostToContainer or Bidirectional) + # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation + # default None + propagation: None + EOF + ``` + + {{}} + + 如果你在 macOS 上使用 Docker Desktop 和 KinD， + 你可以在菜单项 **Preferences > Resources > File Sharing** + 下添加 `/tmp` 作为共享目录。 + {{}} + + +5. 创建一个使用 Pod 安全准入的集群来应用这些 Pod 安全标准： + + ```shell + kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml + ``` + + 输出类似于： + ``` + Creating cluster "psa-with-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-with-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-with-cluster-pss + + Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 + ``` + + +6. 将 kubectl 指向集群 + + ```shell + kubectl cluster-info --context kind-psa-with-cluster-pss + ``` + + 输出类似于： + ``` + Kubernetes control plane is running at https://127.0.0.1:63855 + CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + + +7. 创建以下 Pod 规约作为在 default 名字空间中的一个最小配置： + + ``` + cat < /tmp/pss/nginx-pod.yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 + EOF + ``` + + +8. 在集群中创建 Pod： + + ```shell + kubectl apply -f /tmp/pss/nginx-pod.yaml + ``` + + 输出类似于： + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + + +## 清理 {#clean-up} + +运行 `kind delete cluster -name psa-with-cluster-pss` 和 +`kind delete cluster -name psa-wo-cluster-pss` 来删除你创建的集群。 + +## {{% heading "whatsnext" %}} + + +- 运行一个 [shell 脚本](/zh/examples/security/kind-with-cluster-level-baseline-pod-security.sh) + 一次执行前面的所有步骤： + 1. 创建一个基于 Pod 安全标准的集群级别配置 + 2. 创建一个文件让 API 服务器消费这个配置 + 3. 创建一个集群，用这个配置创建一个 API 服务器 + 4. 设置 kubectl 上下文为这个新集群 + 5. 创建一个最小的 Pod yaml 文件 + 6. 应用这个文件，在新集群中创建一个 Pod +- [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) +- [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) +- [在名字空间级别应用 Pod 安全标准](/zh/docs/tutorials/security/ns-level-pss/) \ No newline at end of file From ce0ede9dc0daacb0b8fd0b3f6c76d8958bfeae0d Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 5 Jan 2022 00:17:28 +0200 Subject: [PATCH 073/145] [ja] remove Open vSwitch --- .../ja/docs/concepts/cluster-administration/networking.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 393829cf2e..4d748e7cef 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -263,12 +263,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also -complicated way to build an overlay network. This is endorsed by several of the -"Big Shops" for networking. - ### OVN (Open Virtual Networking) OVN is an opensource network virtualization solution developed by the From 9f1de9cd8777c33d9ffeb5c76a926dcf8b45585f Mon Sep 17 00:00:00 2001 From: Mike Spreitzer Date: Tue, 4 Jan 2022 21:25:23 -0500 Subject: [PATCH 074/145] Corrected alpha release for APIPriorityAndFairness FeatureGate --- .../reference/command-line-tools-reference/feature-gates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 6eb9e1d40e..ef4e6cf2f1 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -53,7 +53,7 @@ different Kubernetes components. |---------|---------|-------|-------|-------| | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | -| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 | +| `APIPriorityAndFairness` | `false` | Alpha | 1.18 | 1.19 | | `APIPriorityAndFairness` | `true` | Beta | 1.20 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 | | `APIResponseCompression` | `true` | Beta | 1.16 | | From b28500b7a58ba0482f6747f8d441fdda97ca5af6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Tue, 4 Jan 2022 23:59:39 +0800 Subject: [PATCH 075/145] [zh] synchronize translate components.md --- content/zh/docs/concepts/overview/components.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index 26535842ab..a79418ed1d 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -29,9 +29,8 @@ When you deploy Kubernetes, you get a cluster. This document outlines the various components you need to have for a complete and working Kubernetes cluster. -Here's the diagram of a Kubernetes cluster with all the components tied together. +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" >}} -![Components of Kubernetes](/images/docs/components-of-kubernetes.svg) --> 当你部署完 Kubernetes, 即拥有了一个完整的集群。 @@ -39,9 +38,7 @@ Here's the diagram of a Kubernetes cluster with all the components tied together 本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。 -这张图表展示了包含所有相互关联组件的 Kubernetes 集群。 - -![Kubernetes 组件](/images/docs/components-of-kubernetes.svg) +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes 的组件" caption="Kubernetes 集群的组件" class="diagram-large" >}} From e3dd9fe077a4efe5617e3e04f3bff3535575d9cb Mon Sep 17 00:00:00 2001 From: ptux Date: Wed, 5 Jan 2022 22:53:14 +0900 Subject: [PATCH 076/145] done --- .../administer-cluster/kubeadm/_index.md | 5 + .../kubeadm/kubeadm-certs.md | 268 ++++++++++++++++++ 2 files changed, 273 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/kubeadm/_index.md create mode 100644 content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md b/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100644 index 0000000000..9094ab70e6 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,5 @@ +--- +title: "kubeadmによる管理" +weight: 10 +--- + diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md new file mode 100644 index 0000000000..58cc6d47a7 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -0,0 +1,268 @@ +--- +title: kubeadmによる証明書管理 +content_type: task +weight: 10 +--- + + + +{{< feature-state for_k8s_version="v1.15" state="stable" >}} + +[kubeadm](/docs/reference/setup-tools/kubeadm/)で生成されたクライアント証明書は1年で失効します。 +このページでは、kubeadmで証明書の更新を管理する方法について説明します。 + +## {{% heading "prerequisites" %}} + +[KubernetesにおけるPKI証明書と要件](/docs/setup/best-practices/certificates/)を熟知している必要があります。 + + + +## カスタム証明書の使用 {#custom-certificates} + +デフォルトでは、kubeadmはクラスターの実行に必要なすべての証明書を生成します。 +独自の証明書を提供することで、この動作をオーバーライドできます。 + +そのためには、`--cert-dir`フラグまたはkubeadmの`ClusterConfiguration`の`certificatesDir`フィールドで指定された任意のディレクトリに配置する必要があります。 +デフォルトは`/etc/kubernetes/pki`です。 + +`kubeadm init` を実行する前に与えられた証明書と秘密鍵のペアが存在する場合、kubeadmはそれらを上書きしません。 +つまり、例えば既存のCAを`/etc/kubernetes/pki/ca.crt`と`/etc/kubernetes/pki/ca.key`にコピーすれば、kubeadmは残りの証明書に署名する際、このCAを使用できます。 + +## 外部CAモード {#external-ca-mode} + +また、`ca.crt`ファイルのみを提供し、`ca.key`ファイルを提供しないことも可能です(これはルートCAファイルのみに有効で、他の証明書ペアには有効ではありません)。 +他の証明書とkubeconfigファイルがすべて揃っている場合、kubeadmはこの状態を認識し、外部CAモードを有効にします。 +kubeadmはディスク上のCAキーがなくても処理を進めます。 + +代わりに、Controller-managerをスタンドアロンで、`--controllers=csrsigner`と実行し、CA証明書と鍵を指し示します。 + +[PKI certificates and requirements](/docs/setup/best-practices/certificates/)には、外部CAを使用するためのクラスタのセットアップに関するガイダンスが含まれています。 + +## 証明書の有効期限の確認 + +`check-expiration`サブコマンドを使うと、証明書の有効期限を確認することができます。 + +``` +kubeadm certs check-expiration +``` + +このような出力になります: + +``` +CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED +admin.conf Dec 30, 2020 23:36 UTC 364d no +apiserver Dec 30, 2020 23:36 UTC 364d ca no +apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no +apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no +controller-manager.conf Dec 30, 2020 23:36 UTC 364d no +etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no +etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no +etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no +front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no +scheduler.conf Dec 30, 2020 23:36 UTC 364d no + +CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED +ca Dec 28, 2029 23:36 UTC 9y no +etcd-ca Dec 28, 2029 23:36 UTC 9y no +front-proxy-ca Dec 28, 2029 23:36 UTC 9y no +``` + +このコマンドは、`/etc/kubernetes/pki`フォルダ内のクライアント証明書と、kubeadmが使用するKUBECONFIGファイル(`admin.conf`,`controller-manager.conf`,`scheduler.conf`に埋め込まれたクライアント証明書の有効期限/残余時間を表示します)。 + +また、証明書が外部管理されている場合、kubeadmはユーザーに通知します。この場合、ユーザーは証明書の更新を手動または他のツールを使用して管理する必要があります。 + +{{< warning >}} +`kubeadm`は外部CAによって署名された証明書を管理することができません。 +{{< /warning >}} + +{{< note >}} +kubeadmは`/var/lib/kubelet/pki`以下にあるローテート可能な証明書で[証明書の自動更新](/docs/task/tls/certificate-rotation/)のためkubeletを構成するので`kubelet.conf`は上記のリストに含まれません。 + +期限切れのkubeletクライアント証明書を修復するには、[Kubelet クライアント証明書のローテーションに失敗しました](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)を参照ください。 +{{< /note >}} + +{{< warning >}} +kubeadm version 1.17より前の`kubeadm init`で作成したノードでは、`kubelet.conf`の内容を手動で変更しなければならないという[bug](https://github.com/kubernetes/kubeadm/issues/1753)が存在します。 + +`kubeadm init`が終了したら、`client-certificate-data`と`client-key-data`を置き換えて、ローテーションされたkubeletクライアント証明書を指すように`kubelet.conf`を更新してください。 + +```yaml +client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem +client-key: /var/lib/kubelet/pki/kubelet-client-current.pem +``` +{{< /warning >}} + +## 証明書の自動更新 + +kubeadmはコントロールプレーンの[アップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)時にすべての証明書を更新します。 + +この機能は、最もシンプルなユースケースに対応するために設計されています。 +証明書の更新に特別な要件がなく、Kubernetesのバージョンアップを定期的に行う場合(各アップグレードの間隔が1年未満)、kubeadmがクラスタを最新かつ適度に安全に保つための処理を行います。 + +{{< note >}} +安全性を維持するために、クラスタを頻繁にアップグレードすることがベストプラクティスです。 +{{< /note >}} + +証明書の更新に関してより複雑な要求がある場合は、`--certificate-renewal=false`を`kubeadm upgrade apply`や`kubeadm upgrade node`に渡して、デフォルトの動作から外れるようにすることができます。 + +{{< warning >}} +kubeadmバージョン1.17より前のバージョンでは、`kubeadm upgrade node`コマンドの`--certificate-renewal`のデフォルト値が`false`になっているという[bug(https://github.com/kubernetes/kubeadm/issues/1818)]問題があります。 +この場合、明示的に`--certificate-renewal=true`を設定する必要があります。 +{{< /warning >}} + +## 手動による証明書更新 + +`kubeadm certs renew` コマンドを使えば、いつでも証明書を手動で更新することができます。 +このコマンドは`/etc/kubernetes/pki`に格納されているCA(またはfront-proxy-CA)の証明書と鍵を使って更新を行います。 + +コマンド実行後、コントロールプレーンのPodを再起動する必要があります。 +これは、現在すべてのコンポーネントと証明書について動的な証明書のリロードがサポートされていないため、必要な作業です。 +[スタティックPod](/docs/tasks/configure-pod-container/static-pod/)はローカルkubeletによって管理され、API Serverによって管理されないため、kubectlで削除および再起動することはできません。 + +スタティックPodを再起動するには、一時的に`/etc/kubernetes/manifests/`からマニフェストファイルを削除して20秒間待ちます([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)の`fileCheckFrequency`値を参照してください)。 +マニフェストディレクトリにPodが無くなると、kubeletはPodを終了します。 +その後ファイルを戻して、さらに`fileCheckFrequency`期間後に、kubeletはPodを再作成し、コンポーネントの証明書更新を完了することができます。 + +{{< warning >}} +HAクラスタを実行している場合、このコマンドはすべての制御プレーンノードで実行する必要があります。 +{{< /warning >}} + +{{< note >}} +`certs renew`は、属性(Common Name、Organization、SANなど)の信頼できるソースとして、kubeadm-config ConfigMapではなく、既存の証明書を使用します。両者を同期させておくことが強く推奨されます。 +{{< /note >}} + +`kubeadm certs renew` は以下のオプションを提供します: + +Kubernetesの証明書は通常1年後に有効期限を迎えます。 + +- `--csr-only`を使用すると、証明書署名要求を生成して外部CAとの証明書を更新することができます(実際にはその場で証明書を更新しません)。詳しくは次の段落を参照してください。 + +- また、すべての証明書を更新するのではなく、1つの証明書を更新することも可能です。 + +## Kubernetes certificates APIによる証明書の更新 + +ここでは、Kubernetes certificates APIを使用して手動で証明書更新を実行する方法について詳しく説明します。 + +{{< caution >}} +これらは、組織の証明書インフラをkubeadmで構築されたクラスタに統合する必要があるユーザー向けの上級者向けのトピックです。 +kubeadmのデフォルトの設定で満足できる場合は、代わりにkubeadmに証明書を管理させる必要があります。 +{{< /caution >}} + +### 署名者の設定 + +Kubernetesの認証局は、そのままでは機能しません。 +[cert-manager](https://cert-manager.io/docs/configuration/ca/)などの外部署名者を設定するか、組み込みの署名者を使用することができます。 + +ビルトインサイナーは[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)に含まれるものです。 +ビルトインサイナーを有効にするには、`--cluster-signing-cert-file`と`--cluster-signing-key-file`フラグを渡す必要があります。 + +新しいクラスタを作成する場合は、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。 + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +controllerManager: + extraArgs: + cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt + cluster-signing-key-file: /etc/kubernetes/pki/ca.key +``` + +### 証明書署名要求の作成 (CSR) + +Kubernetes APIでのCSR作成については、[Create CertificateSigningRequest](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)を参照ください。 + +## 外部CAによる証明書の更新 + +ここでは、外部認証局を利用して手動で証明書更新を行う方法について詳しく説明します。 + +外部CAとの連携を強化するために、kubeadmは証明書署名要求(CSR)を生成することもできます。 +CSRとは、クライアント用の署名付き証明書をCAに要求することを表します。 +kubeadmの用語では、通常ディスク上のCAによって署名される証明書をCSRとして生成することができます。しかし、CAはCSRとして生成することはできません。 + +### 証明書署名要求の作成 (CSR) + +`kubeadm certs renew --csr-only`で証明書署名要求を作成することができます。 + +CSRとそれに付随する秘密鍵の両方が出力されます。 +ディレクトリを`--csr-dir`で渡すと、指定した場所にCSRを出力することができます。 +csr-dir`を指定しない場合は、デフォルトの証明書ディレクトリ(`/etc/kubernetes/pki`)が使用されます。 + +証明書は`kubeadm certs renew --csr-only`で更新することができます。 +`kubeadm init`と同様に、`--csr-dir`フラグで出力先ディレクトリを指定することができます。 + +CSRには、証明書の名前、ドメイン、IPが含まれますが、用途は指定されません。 +証明書を発行する際に、[正しい証明書の使用法](/docs/setup/best-practices/certificates/#all-certificates)を指定するのはCAの責任です。 + +* `opensl`では、[`openssl ca`コマンド](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)を使って行います。 + +* `cfssl`では、[configファイルのusages](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)で指定します。 + +お好みの方法で証明書に署名した後、証明書と秘密鍵をPKIディレクトリ(デフォルトでは`/etc/kubernetes/pki`)にコピーする必要があります。 + +## 認証局(CA)のローテーション {#certificate-authority-rotation} + +Kubeadmは、CA証明書のローテーションや交換を最初からサポートしているわけではありません。 + +CAの手動ローテーションや交換についての詳細は、[manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/)を参照してください。 + +## 署名付きkubeletサービング証明書の有効化 {#kubelet-serving-certs} + +デフォルトでは、kubeadmによって展開されるkubeletサービング証明書は自己署名されています。 +これは、[metrics-server](https://github.com/kubernetes-sigs/metrics-server)のような外部サービスからキューブレットへの接続がTLSで保護されないことを意味します。 +新しいkubeadmクラスタ内のkubeletが適切に署名されたサービング証明書を取得するように設定するには、`kubeadm init`に以下の最小限の設定を渡す必要があります。 + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +serverTLSBootstrap: true +``` + +すでにクラスタを作成している場合は、以下の手順で適応させる必要があります。 + + - kube-system` ネームスペースにある `kubelet-config-{{< skew latestVersion >}}` ConfigMap を見つけて編集します。 + +そのConfigMapの`kubelet`キーの値として[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ドキュメントを指定します。KubeletConfigurationドキュメントを編集し、`serverTLSBootstrap: true`を設定します。 + +- 各ノードで、`/var/lib/kubelet/config.yaml`に`serverTLSBootstrap: true`フィールドを追加し、`systemctl restart kubelet`でkubeletを再起動します。 + +`serverTLSBootstrap: true`フィールドは、kubeleサービングのブートストラップを有効にします。 +証明書を`certificates.k8s.io`APIにリクエストすることで、証明書を発行することができます。 + +既知の制限事項として、これらの証明書のCSR(Certificate Signing Requests)はkube-controller-managerのデフォルトサイナーによって自動的に承認されないことがあります。 +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers) を参照してください。 + +これには、ユーザーまたはサードパーティのコントローラからのアクションが必要です。 + +これらのCSRは、以下を使用して表示できます: + +```shell +kubectl get csr +NAME AGE SIGNERNAME REQUESTOR CONDITION +csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending +csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending +``` + +承認するためには、次のようにします: +```shell +kubectl certificate approve +``` + +デフォルトでは、これらのサービング証明書は1年後に失効します。 + +Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に設定します。これは有効期限が切れる間際に、サービング証明書のための新しいCSRセットを作成し、ローテーションを完了するために承認する必要があることを意味します。 + +詳しくは[Certificate Rotation] (/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)をご覧ください。 + +これらのCSRを自動的に承認するためのソリューションをお探しの場合は、以下をお勧めします。 +クラウドプロバイダーに連絡し、CSRの署名者がいるかどうか尋ねてください。 +ノードの識別をアウトオブバンドのメカニズムで行います。 + +{{% thirdparty-content %}} + +サードパーティのカスタムコントローラを使用することができます。 +- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver) + +このようなコントローラは、CSRのCommonNameを検証するだけでなく、要求されたIPやドメイン名も検証しなければ、安全なメカニズムとは言えません。これにより、kubeletクライアント証明書にアクセスできる悪意のあるアクターが、任意のIPやドメイン名に対してサービング証明書を要求するCSRを作成することを防ぐことができます。 From 771564690754d3ecb6bdf67b9b4b11cdee0dd2fc Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 7 Oct 2021 10:54:28 +0100 Subject: [PATCH 077/145] Tweak wording for Device Plugins concept --- .../compute-storage-net/device-plugins.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index f14f78b13b..4c65d1e8da 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -48,12 +48,14 @@ For example, after a device plugin registers `hardware-vendor.example/foo` with and reports two healthy devices on a node, the node status is updated to advertise that the node has 2 "Foo" devices installed and available. -Then, users can request devices in a -[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) -specification as they request other types of resources, with the following limitations: - +Then, users can request devices as part of a Pod specification +(see [`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)). +Requesting extended resources is similar to how you manage requests and limits for +other resources, with the following differences: * Extended resources are only supported as integer resources and cannot be overcommitted. -* Devices cannot be shared among Containers. +* Devices cannot be shared between containers. + +### Example {#example-pod} Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo` on certain nodes. Here is an example of a pod requesting this resource to run a demo workload: @@ -174,7 +176,7 @@ a Kubernetes release with a newer device plugin API version, upgrade your device to support both versions before upgrading these nodes. Taking that approach will ensure the continuous functioning of the device allocations during the upgrade. -## Monitoring Device Plugin Resources +## Monitoring device plugin resources {{< feature-state for_k8s_version="v1.15" state="beta" >}} @@ -310,7 +312,7 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20. -## Device Plugin integration with the Topology Manager +## Device plugin integration with the Topology Manager {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -357,5 +359,5 @@ Here are some examples of device plugin implementations: * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node -* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) +* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes From fea1dc28017e92273dbfb3b24ac82d3e1c35ebb4 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 7 Oct 2021 10:54:46 +0100 Subject: [PATCH 078/145] Clean up front matter --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 4c65d1e8da..fe996ec8d6 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -1,7 +1,6 @@ --- -reviewers: title: Device Plugins -description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup. +description: Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory. content_type: concept weight: 20 --- From d67ac4dc950356ae9e599e7e2cea64cb04b3462c Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 7 Oct 2021 10:55:07 +0100 Subject: [PATCH 079/145] Fix mismatched whitespace Convert a tab to spaces to match other lines in snippet. --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index fe996ec8d6..3b9dde2a2a 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -320,7 +320,7 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin ```gRPC message TopologyInfo { - repeated NUMANode nodes = 1; + repeated NUMANode nodes = 1; } message NUMANode { From 2558306e5831ddd65ecf75a267b6e61c6ebc54fb Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 7 Oct 2021 10:55:37 +0100 Subject: [PATCH 080/145] Add third-party content disclaimer --- .../extend-kubernetes/compute-storage-net/device-plugins.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 3b9dde2a2a..8b201e70e6 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -339,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. ## Device plugin examples {#examples} +{{% thirdparty-content %}} + Here are some examples of device plugin implementations: * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) From 4207597a91ced2f5fa4950a7efc11f4a27d117b5 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Thu, 6 Jan 2022 01:37:16 +0000 Subject: [PATCH 081/145] blog post draft: https://docs.google.com/document/d/160edAf2q3-FY8SFNCfEoSWcQ0Y7OUUy4hD7nc-b11n8/edit# --- .../index.md | 6 +- ...kubernetes-is-moving-on-from-dockershim.md | 99 +++++++++++++++++++ 2 files changed, 104 insertions(+), 1 deletion(-) create mode 100644 content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md index b372e7e7b4..6d0f1e9f83 100644 --- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md +++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md @@ -5,6 +5,10 @@ date: 2021-11-12 slug: are-you-ready-for-dockershim-removal --- +{{< note >}} +This poll will close on January 7, 2022. +{{}} + **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano. Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). @@ -25,7 +29,7 @@ are still not ready: [migrating telemetry and security agents](/docs/tasks/admin At this point, we believe that there is feature parity between Docker and the other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/) and are running production workload using these different runtimes. The plan of -record today is that dockershim will be removed in version 1.24, slated for +record today is that dockershim will be removed in version 1.24, slated for release around April of next year. For those developing or running alpha and beta versions, dockershim will be removed in December at the beginning of the 1.24 release development cycle. diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md new file mode 100644 index 0000000000..11fc82f947 --- /dev/null +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -0,0 +1,99 @@ +--- +layout: blog +title: "Kubernetes is moving on from Dockershim: commitments and next steps" +date: 2022-01-07 +slug: kubernetes-is-moving-on-from-dockershim +--- + +**Authors:** Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google) + +Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited +to reaffirm our community values by supporting open source container runtimes, +enable a smaller kubelet, and increase engineering velocity for teams using +Kubernetes. If you [use Docker Engine as a Container Runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) +for your Kubernetes cluster, get ready to migrate to 1.24! To check if you're +affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). + +## Why we’re moving away from dockershim + +Docker was the first container runtime used by Kubernetes. This is one of the +reasons why Docker is so familiar to many Kubernetes users and enthusiasts. +As containerization became an industry standard, the Kubernetes project added support +for additional runtimes. This culminated with the implementation of the +container runtime interface (CRI), letting system components (like the kubelet) +talk to container runtimes in a standardized way. As a result, the hardcoded support for Docker – +a component the project refers to as dockershim – became an anomaly in the Kubernetes project. +Dependencies on Docker and dockershim have crept into various tools +and projects in the CNCF ecosystem ecosystem, resulting in fragile code. + +By removing the +dockershim CRI, we're embracing the first value of CNCF: "[Fast is better than +slow](https://github.com/cncf/foundation/blob/master/charter.md#3-values)". +Stay tuned for future communications on the topic! + +## Deprecation timeline + +We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020.  Full removal is targeted +in Kubernetes 1.24, in April 2022. This timeline +aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior), +which states that deprecated behaviors must function for at least 1 year +after their announced deprecation. + +We'll support Kubernetes version 1.23, which includes +dockershim, for another year in the Kubernetes project. Managed +Kubernetes providers, vendor support is likely to last even longer, but this is +dependent on the companies themselves. Regardless, we're confident all cluster operations will have +time to migrate. If you have more questions about the dockershim removal, refer +to the [Dockershim Deprecation FAQ](/dockershim). + +We asked you whether you feel prepared for the migration from dockershim in this +survey: [Are you ready for Dockershim removal](/blog/2021/11/12/are-you-ready-for-dockershim-removal/). +We had over 600 responses. To everybody who took time filling out the survey, +thank you. + +The results show that we still have a lot of ground to cover to help you to +migrate smoothly. Other container runtimes exist, and have been promoted +extensively. However, many users told us they still rely on dockershim, +and sometimes have dependencies that need to be re-worked. Some of these +dependencies are outside of your control. Based on the feedback received from +you, here are some of the steps we are taking to help. + +## Our next steps + +Based on the feedback you provided: + +- CNCF and the 1.24 release team are committed to delivering documentation in + time for the 1.24 release. This includes more informative blog posts like this + one, updating existing code samples, tutorials, and tasks, and producing a + migration guide for cluster operators. +- We are reaching out to the rest of the CNCF community to help prepare them for + this change. + +If you're part of a project with dependencies on dockershim, or if you're +interested in helping with the migration effort, please join us! There's always +room for more contributors, whether to our transition tools or to our +documentation. To get started, say hello in +[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G) +channel on [Kuberentes Slack](https://slack.kubernetes.io/)! + +## Final thoughts + +As a project, we've already seen cluster operators increasingly adopt of other container runtimes through 2021. +We believe there are no major blockers to migration. The steps we're taking to +improve the migration experience will light the path more clearly for you. + +We understand that migration from dockershim is yet another action you may need to +do to keep your Kubernetes infrastructure up to date. For most of you, this step +will be straightforward and transparent. In some cases, you will encounter +hiccups or issues. The community has discussed at length whether postponing the +dockershim removal would be helpful. For example, we recently talked about it in +the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid) +and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx). +We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it once last year because the adoption rate of other +runtimes was lower than we wanted, which also gave us more time to identify +potential blocking issues. + +At this point, we believe that the value that you (and Kubernetes) gain from +dockershim removal makes up for the migration effort you'll have. Start planning +now to avoid surprises. We'll have more updates and guides before Kubernetes +1.24 is released. From d51b32bab88e918ec7438b9c595d739e9f0c9f51 Mon Sep 17 00:00:00 2001 From: Paco Xu Date: Thu, 6 Jan 2022 11:24:06 +0800 Subject: [PATCH 082/145] storage class parameters value should be string --- content/en/docs/concepts/storage/storage-classes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index f51e10e558..cd9124b6a7 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -434,7 +434,7 @@ provisioner: example.com/external-nfs parameters: server: nfs-server.example.com path: /share - readOnly: false + readOnly: "false" ``` * `server`: Server is the hostname or IP address of the NFS server. @@ -797,7 +797,7 @@ parameters: storagePool: sp1 storageMode: ThinProvisioned secretRef: sio-secret - readOnly: false + readOnly: "false" fsType: xfs ``` From 4030f7fab9fc3a81aeb69314421a7aba4ab0b0fc Mon Sep 17 00:00:00 2001 From: DanStough Date: Thu, 6 Jan 2022 14:50:38 -0500 Subject: [PATCH 083/145] kubeadm: remove ClusterStatus references --- content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md | 2 -- content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md | 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index b5756e5cc2..5693274a59 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -41,8 +41,6 @@ For control-plane nodes additional steps are performed: 1. Adding new local etcd member. -1. Adding this node to the ClusterStatus of the kubeadm cluster. - ### Using join phases with kubeadm {#join-phases} Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`. diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index 93d5ce0cbb..9a5f9b29fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -16,8 +16,7 @@ Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join `kubeadm reset` is responsible for cleaning up a node local file system from files that were created using the `kubeadm init` or `kubeadm join` commands. For control-plane nodes `reset` also removes the local stacked -etcd member of this node from the etcd cluster and also removes this node's information from the kubeadm -`ClusterStatus` object. `ClusterStatus` is a kubeadm managed Kubernetes API object that holds a list of kube-apiserver endpoints. +etcd member of this node from the etcd cluster. `kubeadm reset phase` can be used to execute the separate phases of the above workflow. To skip a list of phases you can use the `--skip-phases` flag, which works in a similar way to From 9617e67e51290b50edc5c9f30175f8d4403d0fd6 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Thu, 6 Jan 2022 12:40:58 -0800 Subject: [PATCH 084/145] Update content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md Co-authored-by: Rey Lejano --- .../2022-01-07-kubernetes-is-moving-on-from-dockershim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md index 11fc82f947..17a38caa5f 100644 --- a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -1,6 +1,6 @@ --- layout: blog -title: "Kubernetes is moving on from Dockershim: commitments and next steps" +title: "Kubernetes is Moving on From Dockershim: Commitments and Next Steps" date: 2022-01-07 slug: kubernetes-is-moving-on-from-dockershim --- From 2a0fb0690f3dfa80a56fe6d35d968d1ea5dcbcf2 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 6 Jan 2022 21:04:13 +0000 Subject: [PATCH 085/145] Mark dockershim survey closed --- .../index.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md index 6d0f1e9f83..a896d0f8c9 100644 --- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md +++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md @@ -5,17 +5,18 @@ date: 2021-11-12 slug: are-you-ready-for-dockershim-removal --- -{{< note >}} -This poll will close on January 7, 2022. -{{}} - **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano. +{{% alert color="info" title="Poll closed" %}} +This poll closed on January 7, 2022. +{{% /alert %}} + Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). Our current plan is to remove dockershim from the Kubernetes codebase soon. We are looking for feedback from you whether you are ready for dockershim removal and to ensure that you are ready when the time comes. -**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**. + +Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8 The dockershim component that enables Docker as a Kubernetes container runtime is being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) @@ -37,7 +38,7 @@ beta versions, dockershim will be removed in December at the beginning of the There is only one month left to give us feedback. We want you to tell us how ready you are. -**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)** +We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8 To better understand preparedness for the dockershim removal, our survey is asking the version of Kubernetes you are currently using, and an estimate of when you think you will adopt Kubernetes 1.24. All the aggregated information From 34036af32149fd9ed94222e8c8f97e29be8b191f Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 25 Oct 2021 18:29:03 -0400 Subject: [PATCH 086/145] Add pt-br/docs/concepts/configuration/secret.md. Create the Brazilian Portuguese translation for the Secrets page. --- .../docs/concepts/configuration/secret.md | 2141 +++++++++++++++++ .../docs/reference/glossary/configmap.md | 2 +- .../glossary/container-env-variables.md | 17 + .../docs/reference/glossary/container.md | 19 + .../pt-br/docs/reference/glossary/secret.md | 2 +- 5 files changed, 2179 insertions(+), 2 deletions(-) create mode 100644 content/pt-br/docs/concepts/configuration/secret.md create mode 100644 content/pt-br/docs/reference/glossary/container-env-variables.md create mode 100644 content/pt-br/docs/reference/glossary/container.md diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..013075c852 --- /dev/null +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -0,0 +1,2141 @@ +--- +title: Secrets +content_type: concept +feature: + title: Secrets e gerenciamento de configuração + description: > + Crie e atualize Secrets e configurações da aplicação sem reconstruir sua imagem + de contêiner e sem expor credenciais na configuração da sua aplicação. +weight: 30 +--- + + + + + + + +Um Secret é um objeto que contém uma pequena quantidade de informação sensível, +como senhas, tokens ou chaves. Este tipo de informação poderia, em outras +circunstâncias, ser colocada diretamente em uma configuração de +{{< glossary_tooltip term_id="pod" >}} ou em uma +{{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de +Secrets evita que você tenha de incluir dados confidenciais no seu código. + + + +Secrets podem ser criados de forma independente dos Pods que os consomem. Isto +reduz o risco de que o Secret e seus dados sejam expostos durante o processo de +criação, visualização e edição ou atualização de Pods. O Kubernetes e as +aplicações que rodam no seu cluster podem também tomar outras precauções com +Secrets, como por exemplo evitar a escrita de dados confidenciais em local de +armazenamento persistente (não-volátil). + + + +Secrets são semelhantes a +{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram +especificamente projetados para conter dados confidenciais. + + + +{{< caution >}} +Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema +de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa +com acesso à API ou ao etcd consegue obter ou modificar um Secret. +Além disso, qualquer pessoa que possui autorização para criar Pods em um namespace +consegue utilizar este privilégio para ler qualquer Secret naquele namespace. Isso +inclui acesso indireto, como por exemplo a permissão para criar Deployments. + +Para utilizar Secrets de forma segura, siga pelo menos as instruções abaixo: +1. [Habilite encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) para Secrets. +1. Habilite ou configure [regras de RBAC](/docs/reference/access-authn-authz/authorization/) +que restrinjam o acesso de leitura a Secrets (incluindo acesso indireto). +1. Quando apropriado, utilize mecanismos como RBAC para limitar quais perfis e +usuários possuem permissão para criar novos Secrets ou substituir Secrets +existentes. + +{{< /caution >}} + + + +## Visão Geral de Secrets + + + +Para utilizar um Secret, um Pod precisa referenciar o Secret. +Um Secret pode ser utilizado em um Pod de três maneiras diferentes: +- Como um [arquivo](#using-secrets-as-files-from-a-pod) em um +{{< glossary_tooltip text="volume" term_id="volume" >}} montado em um ou mais de +seus contêineres. +- Como uma [variável de ambiente](#using-secrets-as-environment-variables) em um +contêiner. +- Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o +Pod. + + + +A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, +os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um +mecanismo que auxilia a automação do registro de nós. + + + +O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um +arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são +opcionais. Os valores das chaves no campo `data` devem ser strings codificadas +no formato base64. Se a conversão para base64 não for desejável, você pode +optar por informar os dados no campo `stringData`, que aceita strings arbitrárias +como valores. + + + +As chaves dos campos `data` e `stringData` devem consistir de caracteres +alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` +são internamente combinados com os dados do campo `data`. Se uma chave aparece +em ambos os campos, o valor informado no campo `stringData` toma a precedência. + +## Tipos de Secrets {#secret-types} + + + +Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` +do objeto Secret, ou algumas opções de linha de comando equivalentes no comando +`kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para +facilitar a manipulação programática de diferentes tipos de dados confidenciais. + + + +O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. +Estes tipos variam em termos de validações efetuadas e limitações que o +Kubernetes impõe neles. + + + +| Tipo embutido | Caso de uso | +|----------------------------------------|----------------------------------------------------| +| `Opaque` | dados arbitrários definidos pelo usuário | +| `kubernetes.io/service-account-token` | token de service account (conta de serviço) | +| `kubernetes.io/dockercfg` | arquivo `~/.dockercfg` serializado | +| `kubernetes.io/dockerconfigjson` | arquivo `~/.docker/config.json` serializado | +| `kubernetes.io/basic-auth` | credenciais para autenticação básica (basic auth) | +| `kubernetes.io/ssh-auth` | credenciais para autenticação SSH | +| `kubernetes.io/tls` | dados para um cliente ou servidor TLS | +| `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | + + + +Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do +campo `type` como uma string não-nula em um objeto Secret. Uma string em branco +é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No +entanto, quando tipos embutidos são utilizados, você precisa atender a todos os +requisitos daquele tipo. + +### Secrets tipo Opaque + + + +`Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado +em um arquivo de configuração. Quando um Secret é criado usando o comando +`kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é +do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo +`Opaque`: +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +O resultado será semelhante ao abaixo: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + + + +A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste +caso, `0` significa que este objeto Secret está vazio. + +### Secrets de token de service account (conta de serviço) + + + +Secrets do tipo `kubernetes.io/service-account-token` são utilizados para +armazenar um token que identifica uma service account (conta de serviço). Ao +utilizar este tipo de Secret, você deve garantir que a anotação +`kubernetes.io/service-account.name` contém um nome de uma service account +existente. Um controlador do Kubernetes preenche outros campos, como por exemplo +a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` +com o conteúdo do token. + + +O exemplo de configuração abaixo declara um Secret de token de service account: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account-name: "sa-name" +type: kubernetes.io/service-account-token +data: + # Você pode incluir pares chave-valor adicionais, da mesma forma que faria com + # Secrets do tipo Opaque + extra: YmFyCg== +``` + + + +Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes +automaticamente cria um Secret de service account e automaticamente atualiza o +seu Pod para utilizar este Secret. O Secret de token de service account contém +credenciais para acessar a API. + + + +A criação automática e o uso de credenciais de API podem ser desativados se +desejado. Porém, se tudo que você necessita é poder acessar o servidor da API +de forma segura, este é o processo recomendado. + + + +Veja a documentação de +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) +para mais informações sobre o funcionamento de service accounts. Você pode +verificar também os campos `automountServiceAccountToken` e `serviceAccountName` +do [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +para mais informações sobre como referenciar service accounts em Pods. + +### Secrets de configuração do Docker + + + +Você pode utilizar um dos tipos abaixo para criar um Secret que armazena +credenciais para accesso a um registro de contêineres compatível com Docker +para busca de imagens: +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + + +O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo +`~/.dockercfg` serializado. Este arquivo é o formato legado para configuração +do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, +é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor +é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. + + + +O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um +conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo +`~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo +do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo +`data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo +`~/.docker/config.json` é fornecido codificado no formato base64. + + + +Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + + + +{{< note >}} +Se você não desejar fazer a codificação em formato base64, você pode utilizar o +campo `stringData` como alternativa. +{{< /note >}} + + + +Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor +da API verifica se a chave esperada existe no campo `data` e se o valor fornecido +pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica +se o conteúdo informado é realmente um arquivo de configuração do Docker. + + + +Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o +comando `kubectl` para criar um Secret de registro de contêineres compatível +com o Docker, você pode executar: +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 +``` + + + +Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo +conteúdo é semelhante ao exemplo abaixo: + +```json +{ + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" +} +``` + +Se você extrair o conteúdo da chave `.dockerconfigjson`, presente no campo +`data`, e decodificá-lo do formato base64, você irá obter o objeto JSON abaixo, +que é uma configuração válida do Docker criada automaticamente: + +```json +{ + "auths":{ + "my-registry:5000":{ + "username":"tiger", + "password":"pass113", + "email":"tiger@acme.com", + "auth":"dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### Secret de autenticação básica + + + +O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais +necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo +`data` do Secret deve conter as duas chaves abaixo: +- `username`: o usuário utilizado para autenticação; +- `password`: a senha ou token para autenticação. + + + +Ambos os valores para estas duas chaves são textos codificados em formato base64. +Você pode fornecer os valores como texto simples utilizando o campo `stringData` +na criação do Secret. + +O arquivo YAML abaixo é um exemplo de configuração para um Secret de autenticação +básica: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + + + +O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode +criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, +utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas +credenciais. O tipo embutido também fornece verificação de presença das chaves +requeridas pelo servidor da API. + +### Secret de autenticação SSH + + + +O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados +utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve +especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo +`stringData` com a credencial SSH a ser utilizada. + +O YAML abaixo é um exemplo de configuração para um Secret de autenticação SSH: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # os dados estão abreviados neste exemplo + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + + + +O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. +Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para +autenticação SSH. No entanto, a utilização do tipo embutido auxilia na +unificação dos formatos das suas credenciais e o servidor da API fornece +verificação dos campos requeridos em uma configuração de Secret. + + + +{{< caution >}} +Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável +entre um cliente SSH e um servidor. Uma forma secundária de estabelecer +confiança é necessária para mitigar ataques "machine-in-the-middle", como +por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. +{{< /caution >}} + +### Secrets TLS + + + +O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para +armazenamento de um certificado e sua chave associada que são tipicamente +utilizados para TLS. Estes dados são utilizados primariamente para a +finalização TLS do recurso Ingress, mas podem ser utilizados com outros +recursos ou diretamente por uma carga de trabalho. Ao utilizar este tipo de +Secret, as chaves `tls.key` e `tls.crt` devem ser informadas no campo `data` +(ou `stringData`) da configuração do Secret, embora o servidor da API não +valide o conteúdo de cada uma destas chaves. + +O YAML a seguir tem um exemplo de configuração para um Secret TLS: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # os dados estão abreviados neste exemplo + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + + + +O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um +Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou +cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a +consistência dos formatos de Secret no seu projeto; o servidor da API +valida se os campos requeridos estão presentes na configuração do Secret. + +Ao criar um Secret TLS utilizando a ferramenta de linha de comando `kubectl`, +você pode utilizar o subcomando `tls` conforme demonstrado no exemplo abaixo: +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + + + +O par de chaves pública/privada deve ser criado separadamente. O certificado +de chave pública a ser utilizado no argumento `--cert` deve ser codificado em +formato .PEM (formato DER codificado em texto base64) e deve corresponder à +chave privada fornecida no argumento `--key`. +A chave privada deve estar no formato de chave privada PEM não-encriptado. Em +ambos os casos, as linhas inicial e final do formato PEM (por exemplo, +`--------BEGIN CERTIFICATE-----` e `-------END CERTIFICATE----` para um +certificado) *não* são incluídas. + +### Secret de token de autoinicialização {#bootstrap-token-secrets} + + + +Um Secret de token de autoinicialização pode ser criado especificando o tipo de +um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo +de Secret é projetado para tokens utilizados durante o processo de inicialização +de nós. Este tipo de Secret armazena tokens utilizados para assinar ConfigMaps +conhecidos. + +Um Secret de token de autoinicialização é normalmente criado no namespace +`kube-system` e nomeado na forma `bootstrap-token-`, onde +`` é um texto com 6 caracteres contendo a identificação do token. + +No formato de manifesto do Kubernetes, um Secret de token de autoinicialização +se assemelha ao exemplo abaixo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + + + +Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo +`data`: +- `token-id`: Uma string com 6 caracteres aleatórios como identificador do + token. Requerido. +- `token-secret`: Uma string de 16 caracteres aleatórios como o conteúdo do + token. Requerido. +- `description`: Uma string contendo uma descrição do propósito para o qual este + token é utilizado. Opcional. +- `expiration`: Um horário absoluto UTC no formato RFC3339 especificando quando + o token deve expirar. Opcional. +- `usage-bootstrap-`: Um conjunto de flags booleanas indicando outros + usos para este token de autoinicialização. +- `auth-extra-groups`: Uma lista separada por vírgulas de nomes de grupos que + serão autenticados adicionalmente, além do grupo `system:bootstrappers`. + +O YAML acima pode parecer confuso, já que os valores estão todos codificados em +formato base64. Você pode criar o mesmo Secret utilizando este YAML: +```yaml +apiVersion: v1 +kind: Secret +metadata: + # Observe como o Secret é nomeado + name: bootstrap-token-5emitj + # Um Secret de token de inicialização geralmente fica armazenado no namespace + # kube-system + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # Esta identificação de token é utilizada no nome + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # Este token pode ser utilizado para autenticação. + usage-bootstrap-authentication: "true" + # e pode ser utilizado para assinaturas + usage-bootstrap-signing: "true" +``` + +## Criando um Secret + + + +Há várias formas diferentes de criar um Secret: +- [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [criar um Secret utilizando a ferramenta kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +## Editando um Secret + + +Um Secret existente no cluster pode ser editado com o seguinte comando: +```shell +kubectl edit secrets mysecret +``` + + + +Este comando abrirá o editor padrão configurado e permitirá a modificação dos +valores codificados em base64 no campo `data`: +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## Utilizando Secrets + + + +Secrets podem ser montados como volumes de dados ou expostos como +{{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} +para serem utilizados num container de um Pod. Secrets também podem ser +utilizados por outras partes do sistema, sem serem diretamente expostos ao Pod. +Por exemplo, Secrets podem conter credenciais que outras partes do sistema devem +utilizar para interagir com sistemas externos no lugar do usuário. + +### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} + + + +Para consumir um Secret em um volume em um Pod: +1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem +referenciar o mesmo secret. +1. Modifique sua definição de Pod para adicionar um volume na lista +`.spec.volumes[]`. Escolha um nome qualquer para o seu volume e adicione um +campo `.spec.volumes[].secret.secretName` com o mesmo valor do seu objeto +Secret. +1. Adicione um ponto de montagem de volume à lista +`.spec.containers[].volumeMounts[]` de cada contêiner que requer o Secret. +Especifique `.spec.containers[].volumeMounts[].readOnly = true` e especifique o +valor do campo `.spec.containers[].volumeMounts[].mountPath` com o nome de um +diretório não utilizado onde você deseja que os Secrets apareçam. +1. Modifique sua imagem ou linha de comando de modo que o programa procure por +arquivos naquele diretório. Cada chave no campo `data` se torna um nome de +arquivo no diretório especificado em `mountPath`. + +Este é um exemplo de Pod que monta um Secret em um volume: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + + + +Cada Secret que você deseja utilizar deve ser referenciado na lista +`.spec.volumes`. + +Se existirem múltiplos contêineres em um Pod, cada um dos contêineres necessitará +seu próprio bloco `volumeMounts`, mas somente um volume na lista `.spec.volumes` +é necessário por Secret. + +Você pode armazenar vários arquivos em um Secret ou utilizar vários Secrets +distintos, o que for mais conveniente. + +#### Projeção de chaves de Secrets a caminhos específicos + + +Você pode também controlar os caminhos dentro do volume onde as chaves do Secret +são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para +mudar o caminho de destino de cada chave: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + + + +Neste caso: +* O valor da chave `username` é armazenado no arquivo +`/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. +* O valor da chave `password` não é projetado no sistema de arquivos. + +Se `.spec.volumes[].secret.items` for utilizado, somente chaves especificadas +na lista `items` são projetadas. Para consumir todas as chaves do Secret, deve +haver um item para cada chave no campo `items`. Todas as chaves listadas precisam +existir no Secret correspondente. Caso contrário, o volume não é criado. + +#### Permissões de arquivos de Secret + + + +Você pode trocar os bits de permissão de uma chave avulsa de Secret. +Se nenhuma permissão for especificada, `0644` é utilizado por padrão. +Você pode também especificar uma permissão padrão para o volume inteiro de +Secret e sobrescrever esta permissão por chave, se necessário. + +Por exemplo, você pode especificar uma permissão padrão da seguinte maneira: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + + + +Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados +no volume terão a permissão `0400`. + +Note que a especificação JSON não suporta notação octal. Neste caso, utilize o +valor 256 para permissões equivalentes a 0400. Se você utilizar YAML ao invés +de JSON para o Pod, você pode utilizar notação octal para especificar permissões +de uma forma mais natural. + +Perceba que se você acessar o Pod com `kubectl exec`, você precisará seguir o +vínculo simbólico para encontrar a permissão esperada. Por exemplo, + +Verifique as permissões do arquivo de Secret no pod. +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + + +Siga o vínculo simbólico para encontrar a permissão correta do arquivo. +``` +cd /etc/foo/..data +ls -l +``` + + +O resultado é semelhante ao abaixo: +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + + + +Você pode também utilizar mapeamento, como no exemplo anterior, e especificar +permissões diferentes para arquivos diferentes conforme abaixo: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + + + +Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as +permissões `0777`. Se você utilizar JSON, devido às limitações do formato, +você precisará informar as permissões em base decimal, ou o valor `511` neste +exemplo. + +Note que os valores de permissões podem ser exibidos em formato decimal se você +ler essa informação posteriormente. + +#### Consumindo valores de Secrets em volumes + + + +Dentro do contêiner que monta um volume de Secret, as chaves deste Secret +aparecem como arquivos e os valores dos Secrets são decodificados do formato +base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do +contêiner do exemplo anterior, obteremos os seguintes resultados: + +```shell +ls /etc/foo +``` + + +O resultado é semelhante a: +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + + +O resultado é semelhante a: +``` +admin +``` + +```shell +cat /etc/foo/password +``` + + +O resultado é semelhante a: +``` +1f2d1e2e67df +``` + + + +A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets +dentro dos arquivos. + +#### Secrets montados são atualizados automaticamente + + + +Quando um Secret que está sendo consumido a partir de um volume é atualizado, as +chaves projetadas são atualizadas após algum tempo também. O kubelet verifica +se o Secret montado está atualizado a cada sincronização periódica. No entanto, +o kubelet utiliza seu cache local para buscar o valor corrente de um Secret. O +tipo do cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` +na estrutura [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/). +Um Secret pode ser propagado através de um _watch_ (comportamento padrão), que +é o sistema de propagação de mudanças incrementais em objetos do Kubernetes; +baseado em TTL (_time to live_, ou tempo de expiração); ou redirecionando todas +as requisições diretamente para o servidor da API. + +Como resultado, o tempo decorrido total entre o momento em que o Secret foi +atualizado até o momento em que as novas chaves são projetadas nos Pods pode +ser tão longo quanto o tempo de sincronização do kubelet somado ao tempo de +propagação do cache, onde o tempo de propagação do cache depende do tipo de +cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação +do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. + + + +{{< note >}} +Um contêiner que utiliza Secrets através de um ponto de montagem com a +propriedade +[subPath](/docs/concepts/storage/volumes#using-subpath) não recebe atualizações +deste Secret. +{{< /note >}} + +### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} + + + +Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} +em um Pod: + +1. Crie um Secret ou utilize um já existente. Múltiplos Pods podem referenciar o +mesmo Secret. +1. Modifique a definição de cada contêiner do Pod em que desejar consumir o +Secret, adicionando uma variável de ambiente para cada uma das chaves que deseja +consumir. +A variável de ambiente que consumir o valor da chave em questão deverá popular o +nome do Secret e a sua chave correspondente no campo +`env[].valueFrom.secretKeyRef`. +1. Modifique sua imagem de contêiner ou linha de comando de forma que o programa +busque os valores nas variáveis de ambiente especificadas. + +Este é um exemplo de um Pod que utiliza Secrets em variáveis de ambiente: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### Consumindo valores de Secret em variáveis de ambiente + + + +Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave +do Secret aparece como uma variável de ambiente comum, contendo os dados do +Secret decodificados do formato base64. Ao executar comandos no contêiner do +exemplo anterior, obteremos os resultados abaixo: + +```shell +echo $SECRET_USERNAME +``` + + +O resultado é semelhante a: + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +O resultado é semelhante a: + +``` +1f2d1e2e67df +``` + +#### Variáveis de ambiente não são atualizadas após uma atualização no Secret + + + +Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização +dos valores do Secret não será refletida no contêiner a menos que o contêiner +seja reiniciado. +Existem ferramentas de terceiros que oferecem reinicializações automáticas +quando Secrets são atualizados. + +## Secrets imutáveis {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + + + +A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma +opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters +que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens +únicas de Secrets em Pods), prevenir alterações aos dados dos Secrets traz as +seguintes vantagens: +- protege você de alterações acidentais ou indesejadas que poderiam provocar +disrupções na execução de aplicações; +- melhora a performance do seu cluster através da redução significativa de carga +no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como +imutáveis. + + + +Esta funcionalidade é controlada pelo +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão +v1.19. Você pode criar um Secret imutável adicionando o campo `immutable` com +o valor `true`. Por exemplo: +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + + + +{{< note >}} +Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais +possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você +pode somente apagar e recriar o Secret. Pods existentes mantém um ponto de +montagem referenciando o Secret removido - é recomendado recriar tais Pods. +{{< /note >}} + +### Usando `imagePullSecrets` {#using-imagepullsecrets} + + + +O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo +namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets +que contém uma senha para acesso a um registro de contêineres do Docker (ou +outros registros de contêineres) ao kubelet. O kubelet utiliza essa informação +para baixar uma imagem privada no lugar do seu Pod. +Veja a [API PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +para maiores detalhes sobre o campo `imagePullSecrets`. + +#### Especificando `imagePullSecrets` manualmente + + + +Você pode ler sobre como especificar `imagePullSecrets` em um Pod na +[documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). + +### Configurando `imagePullSecrets` para serem vinculados automaticamente + + + +Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma +ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada +explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os +mesmos valores existentes na service account. +Veja [adicionando `imagePullSecrets` a uma service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +para uma explicação detalhada do processo. + +## Detalhes + +### Restrições + + + +Referências a Secrets em volumes são validadas para garantir que o objeto +especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret +precisa ser criado antes de quaisquer Pods que dependam deste. + + + +Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +Secrets podem ser referenciados somente por Pods no mesmo namespace. + + + +Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por +objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir +a memória do servidor da API e do kubelet. No entanto, a criação de muitos +Secrets pequenos também pode exaurir a memória. Limites mais completos de uso +de memória em função de Secrets é uma funcionalidade prevista para o futuro. + + + +O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos +do servidor da API. Isso inclui quaisquer Pods criados usando o comando +`kubectl`, ou indiretamente através de um controlador de replicação, mas não +inclui Pods criados como resultado das flags `--manifest-url` e `--config` do +kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). +A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} +não pode se referir a um Secret ou a qualquer outro objeto da API. + + + +Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de +ambiente, exceto quando são marcados como opcionais. Referências a Secrets que +não existem provocam falhas na inicialização do Pod. + + + +Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado +provocam falhas na inicialização do Pod. + + + +Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` +que contém chaves inválidas para utilização como nome de uma variável de ambiente +terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento +será gerado com a razão `InvalidVariableNames` e a mensagem gerada conterá a lista +de chaves inválidas que foram ignoradas. O exemplo abaixo demonstra um Pod que se +refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e +`2alsobad`. + +```shell +kubectl get events +``` + + +O resultado é semelhante a: + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Interações do ciclo de vida entre Secrets e Pods + + + +Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação +da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o +kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado +porque não existe ou porque houve uma falha de comunicação temporária entre o +kubelet e o servidor da API, o kubelet fará novas tentativas periodicamente. +O kubelet irá gerar um evento sobre o Pod, explicando a razão pela qual o Pod +ainda não foi inicializado. Uma vez que o Secret tenha sido encontrado, o +kubelet irá criar e montar um volume contendo este Secret. Nenhum dos contêineres +do Pod irá iniciar até que todos os volumes estejam montados. + +## Casos de uso + +### Caso de uso: Como variáveis de ambiente em um contêiner + + +Crie um manifesto de Secret + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + + +Crie o Secret no seu cluster: + +```shell +kubectl apply -f mysecret.yaml +``` + + +Utilize `envFrom` para definir todos os dados do Secret como variáveis de +ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de +ambiente no Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### Caso de uso: Pod com chaves SSH + + +Crie um Secret contendo chaves SSH: + +```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 +``` + + +O resultado é semelhante a: + +``` +secret "ssh-key-secret" created +``` + + + +Você também pode criar um manifesto `kustomization.yaml` com um campo +`secretGenerator` contendo chaves SSH. + +{{< caution >}} +Analise cuidadosamente antes de enviar suas próprias chaves SSH: outros usuários +do cluster podem ter acesso a este Secret. Utilize uma service account que você +deseje que seja acessível a todos os usuários com os quais você compartilha o +cluster do Kubernetes em questão. Desse modo, você pode revogar esta service +account caso os usuários sejam comprometidos. +{{< /caution >}} + +Agora você pode criar um Pod que referencia o Secret com a chave SSH e consome-o +em um 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" +``` + + +Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + + + +O contêiner então pode utilizar os dados do secret para estabelecer uma conexão +SSH. + +### Caso de uso: Pods com credenciais de ambientes de produção ou testes + + + +Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um +ambiente de produção e outro Pod que consome um Secret contendo credenciais de +um ambiente de testes. + +Você pode criar um manifesto `kustomization.yaml` com um `secretGenerator` ou +rodar `kubectl create secret`. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + + +O resultado é semelhante a: + +``` +secret "prod-db-secret" created +``` + + +Você pode também criar um Secret com credenciais para o ambiente de testes. + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + + +O resultado é semelhante a: + +``` +secret "test-db-secret" created +``` + + + +{{< note >}} +Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu +[shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de +sequências de escape. Na maioria dos shells, a forma mais fácil de gerar sequências +de escape para suas senhas é escrevê-las entre aspas simples (`'`). Por exemplo, +se a sua senha for `S!B\*d$zDsb=`, você deve executar o comando da seguinte +forma: + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +Não é necessário gerar sequências de escape para caracteres especiais em arquivos +(utilizados com a opção `--from-file`). +{{< /note >}} + +Agora, crie os 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 +``` + + +Adicione os Pods a um manifesto `kustomization.yaml`: + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + + +Crie todos estes objetos no servidor da API rodando o comando: + +```shell +kubectl apply -k . +``` + + + +Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de +arquivos, com valores para cada um dos ambientes dos contêineres: + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + + + +Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso +facilita a criação de Pods com capacidades diferentes a partir de um template +mais genérico. + +Você pode simplificar ainda mais a definição básica do Pod através da utilização +de duas service accounts diferentes: + +1. `prod-user` com o Secret `prod-db-secret` +1. `test-user` com o Secret `test-db-secret` + +A especificação do Pod é reduzida para: + +```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 +``` + +### Caso de uso: _dotfiles_ em um volume de Secret + + + +Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se +inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou +arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um 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: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + + + +Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner +`dotfile-test-container` terá este arquivo presente no caminho +`/etc/secret-volume/.secret-file`. + +{{< note >}} +Arquivos com nomes iniciados por um caractere de ponto são ocultos do resultado +do comando `ls -l`. Você precisa utilizar `ls -la` para vê-los ao listar o +conteúdo de um diretório. +{{< /note >}} + +### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} + + + +Suponha que um programa necessita manipular requisições HTTP, executar regras +de negócio complexas e então assinar mensagens com HMAC. Devido à natureza +complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos +remotos no servidor e que poderia expor a chave privada para um invasor. + +Esta aplicação poderia ser dividida em dois processos, separados em dois +contêineres distintos: um contêiner de _front-end_, que manipula as interações +com o usuário e a lógica de negócio, mas não consegue ver a chave privada; e +um contêiner assinador, que vê a chave privada e responde a requisições simples +de assinatura do _front-end_ (por exemplo, através de rede local). + +Com essa abordagem particionada, um invasor agora precisa forçar o servidor de +aplicação a rodar comandos arbitrários, o que é mais difícil de ser feito do que +apenas ler um arquivo presente no disco. + + + +## Melhores práticas + +### Clientes que utilizam a API de Secrets + + + +Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o +acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) +como [RBAC](/docs/reference/access-authn-authz/rbac/). + + + +Secrets frequentemente contém valores com um espectro de importância, muitos dos +quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service +account) e de sistemas externos. Mesmo que um aplicativo individual possa +avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro +do mesmo namespace podem tornar estas suposições inválidas. + + + +Por estas razões, as requisições `watch` (observar) e `list` (listar) de +Secrets dentro de um namespace são permissões extremamente poderosas e devem +ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os +valores de todos os Secrets presentes naquele namespace. A habilidade de listar +e observar todos os Secrets em um cluster deve ser reservada somente para os +componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. + + + +Aplicações que necessitam acessar a API de Secret devem realizar uma requisição +`get` nos Secrets que precisam. Isto permite que administradores restrinjam o +acesso a todos os Secrets, enquanto +[utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +que a aplicação precise. + + + +Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar +objetos que referenciam o Secret e então utilizar a requisição `watch` neste +novo objeto, requisitanto o Secret novamente quando a referência mudar. +Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) +para permitir a clientes observar recursos individuais também foi proposta e +provavelmente estará disponível em versões futuras do Kubernetes. + +## Propriedades de segurança + +### Proteções + + + +Como Secrets podem ser criados de forma independente de Pods que os utilizam, +há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, +visualização, e edição de Pods. O sistema pode também tomar precauções adicionais +com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. + + + +Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet +armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret +seja escrito em armazenamento persistente. Uma vez que o Pod que depende do +Secret é removido, o kubelet apaga sua cópia local do Secret também. + + + +Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente +os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. +Portanto, um Pod não tem acesso aos Secrets de outro Pod. + + + +Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa +requerer o volume de Secret nos seus `volumeMounts` para que este fique visível +dentro do contêiner. Esta característica pode ser utilizada para construir +[partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). + + + +Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o +servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. +Secrets são protegidos quando transmitidos através destes canais. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + + + +Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) +em dados de Secret para evitar que estes sejam armazenados em texto plano no +{{< glossary_tooltip term_id="etcd" >}}. + +### Riscos + + + +- No servidor da API, os dados de Secret são armazenados no + {{< glossary_tooltip term_id="etcd" >}}; portanto: + - Administradores devem habilitar encriptação em disco para dados do cluster + (requer Kubernetes v1.13 ou posterior). + - Administradores devem limitar o acesso ao etcd somente para usuários + administradores. + - Administradores podem desejar apagar definitivamente ou destruir discos + previamente utilizados pelo etcd que não estiverem mais em uso. + - Ao executar o etcd em um cluster, administradores devem garantir o uso de + SSL/TLS para conexões ponto-a-ponto do etcd. +- Se você configurar um Secret utilizando um arquivo de manifesto (JSON ou + YAML) que contém os dados do Secret codificados como base64, compartilhar + este arquivo ou salvá-lo num sistema de controle de versão de código-fonte + compromete este Secret. Codificação base64 _não_ é um método de encriptação + e deve ser considerada idêntica a texto plano. +- Aplicações ainda precisam proteger o valor do Secret após lê-lo de um volume, + como por exemplo não escrever seu valor em logs ou enviá-lo para um sistema + não-confiável. +- Um usuário que consegue criar um Pod que utiliza um Secret também consegue + ler o valor daquele Secret. Mesmo que o servidor da API possua políticas para + impedir que aquele usuário leia o valor do Secret, o usuário poderia criar um + Pod que expõe o Secret. + +## {{% heading "whatsnext" %}} + + + +- Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Leia a [documentação de referência da API](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) de `Secrets` diff --git a/content/pt-br/docs/reference/glossary/configmap.md b/content/pt-br/docs/reference/glossary/configmap.md index a1ccdea668..4840cdb4ac 100644 --- a/content/pt-br/docs/reference/glossary/configmap.md +++ b/content/pt-br/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2021-08-24 -full_link: /docs/concepts/configuration/configmap +full_link: /pt-br/docs/concepts/configuration/configmap short_description: > Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume. diff --git a/content/pt-br/docs/reference/glossary/container-env-variables.md b/content/pt-br/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000..620dee723c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Variáveis de Ambiente de Contêineres +id: container-env-variables +date: 2021-11-20 +full_link: /pt-br/docs/concepts/containers/container-environment/ +short_description: > + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um Pod. + +aka: +tags: +- fundamental +--- + Variáveis de ambiente de contêineres são pares nome=valor que trazem informações úteis para os contêineres rodando dentro de um {{< glossary_tooltip text="pod" term_id="Pod" >}} + + + +Variáveis de ambiente de contêineres fornecem informações requeridas pela aplicação conteinerizada, junto com informações sobre recursos importantes para o {{< glossary_tooltip text="contêiner" term_id="container" >}}. Por exemplo, detalhes do sistema de arquivos, informações sobre o contêiner, e outros recursos do cluster, como endpoints de serviços. diff --git a/content/pt-br/docs/reference/glossary/container.md b/content/pt-br/docs/reference/glossary/container.md new file mode 100644 index 0000000000..7e24fa5ad7 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: Contêiner +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + Uma imagem executável leve e portável que contém software e todas as suas dependências. + +aka: +tags: +- fundamental +- workload +--- + Uma imagem executável leve e portável que contém software e todas as suas dependências. + + + +Contêineres desacoplam aplicações da infraestrutura da máquina em que estas rodam para tornar a instalação mais fácil em diferentes ambientes de nuvem e de +sistemas operacionais, e para facilitar o escalonamento das aplicações. diff --git a/content/pt-br/docs/reference/glossary/secret.md b/content/pt-br/docs/reference/glossary/secret.md index abcd1bb421..b293f7acc4 100644 --- a/content/pt-br/docs/reference/glossary/secret.md +++ b/content/pt-br/docs/reference/glossary/secret.md @@ -2,7 +2,7 @@ title: Secret id: secret date: 2021-08-24 -full_link: /docs/concepts/configuration/secret/ +full_link: /pt-br/docs/concepts/configuration/secret/ short_description: > Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH. From 9cf1da909660d9de51c1bf723be781f07ce6efa1 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Mon, 29 Nov 2021 20:58:39 -0500 Subject: [PATCH 087/145] Fix typo on translation. --- content/pt-br/docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 013075c852..a15a93cd70 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -2005,7 +2005,7 @@ be available in future releases of Kubernetes. Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste -novo objeto, requisitanto o Secret novamente quando a referência mudar. +novo objeto, requisitando o Secret novamente quando a referência mudar. Além disso, uma [API de "observação em lotes"](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md) para permitir a clientes observar recursos individuais também foi proposta e provavelmente estará disponível em versões futuras do Kubernetes. From 735c85364bb254d92a280f2914544abe1b026169 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:28:08 -0500 Subject: [PATCH 088/145] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 775 +----------------- 1 file changed, 2 insertions(+), 773 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index a15a93cd70..1638aa4faf 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -39,14 +39,6 @@ circunstâncias, ser colocada diretamente em uma configuração de {{< glossary_tooltip text="imagem de contêiner" term_id="image" >}}. O uso de Secrets evita que você tenha de incluir dados confidenciais no seu código. - - Secrets podem ser criados de forma independente dos Pods que os consomem. Isto reduz o risco de que o Secret e seus dados sejam expostos durante o processo de criação, visualização e edição ou atualização de Pods. O Kubernetes e as @@ -54,30 +46,10 @@ aplicações que rodam no seu cluster podem também tomar outras precauções co Secrets, como por exemplo evitar a escrita de dados confidenciais em local de armazenamento persistente (não-volátil). - - Secrets são semelhantes a {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}, mas foram especificamente projetados para conter dados confidenciais. - - {{< caution >}} Os Secrets do Kubernetes são, por padrão, gravados não-encriptados no sistema de armazenamento de dados utilizado pelo servidor da API (etcd). Qualquer pessoa @@ -100,17 +72,6 @@ existentes. ## Visão Geral de Secrets - - Para utilizar um Secret, um Pod precisa referenciar o Secret. Um Secret pode ser utilizado em um Pod de três maneiras diferentes: - Como um [arquivo](#using-secrets-as-files-from-a-pod) em um @@ -121,26 +82,10 @@ contêiner. - Pelo [kubelet ao baixar imagens de contêiner](#using-imagepullsecrets) para o Pod. - - A camada de gerenciamento do Kubernetes também utiliza Secrets. Por exemplo, os [Secrets de tokens de autoinicialização](#bootstrap-token-secrets) são um mecanismo que auxilia a automação do registro de nós. - - O nome de um Secret deve ser um [subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). Você pode especificar o campo `data` e/ou o campo `stringData` na criação de um arquivo de configuração de um Secret. Ambos os campos `data` e `stringData` são @@ -149,14 +94,6 @@ no formato base64. Se a conversão para base64 não for desejável, você pode optar por informar os dados no campo `stringData`, que aceita strings arbitrárias como valores. - - As chaves dos campos `data` e `stringData` devem consistir de caracteres alfanuméricos, `-`, `_`, ou `.`. Todos os pares chave-valor no campo `stringData` são internamente combinados com os dados do campo `data`. Se uma chave aparece @@ -164,41 +101,15 @@ em ambos os campos, o valor informado no campo `stringData` toma a precedência. ## Tipos de Secrets {#secret-types} - - Ao criar um Secret, você pode especificar o seu tipo utilizando o campo `type` do objeto Secret, ou algumas opções de linha de comando equivalentes no comando `kubectl`, quando disponíveis. O campo `type` de um Secret é utilizado para facilitar a manipulação programática de diferentes tipos de dados confidenciais. - - O Kubernetes oferece vários tipos embutidos de Secret para casos de uso comuns. Estes tipos variam em termos de validações efetuadas e limitações que o Kubernetes impõe neles. - - | Tipo embutido | Caso de uso | |----------------------------------------|----------------------------------------------------| | `Opaque` | dados arbitrários definidos pelo usuário | @@ -210,14 +121,6 @@ Kubernetes impõe neles. | `kubernetes.io/tls` | dados para um cliente ou servidor TLS | | `bootstrap.kubernetes.io/token` | dados de token de autoinicialização | - - Você pode definir e utilizar seu próprio tipo de Secret definindo o valor do campo `type` como uma string não-nula em um objeto Secret. Uma string em branco é tratada como o tipo `Opaque`. O Kubernetes não restringe nomes de tipos. No @@ -226,13 +129,6 @@ requisitos daquele tipo. ### Secrets tipo Opaque - - `Opaque` é o tipo predefinido de Secret quando o campo `type` não é informado em um arquivo de configuração. Quando um Secret é criado usando o comando `kubectl`, você deve usar o subcomando `generic` para indicar que um Secret é @@ -242,7 +138,7 @@ do tipo `Opaque`. Por exemplo, o comando a seguir cria um Secret vazio do tipo kubectl create secret generic empty-secret kubectl get secret empty-secret ``` - + O resultado será semelhante ao abaixo: ``` @@ -250,25 +146,11 @@ NAME TYPE DATA AGE empty-secret Opaque 0 2m6s ``` - - A coluna `DATA` demonstra a quantidade de dados armazenados no Secret. Neste caso, `0` significa que este objeto Secret está vazio. ### Secrets de token de service account (conta de serviço) - - Secrets do tipo `kubernetes.io/service-account-token` são utilizados para armazenar um token que identifica uma service account (conta de serviço). Ao utilizar este tipo de Secret, você deve garantir que a anotação @@ -277,7 +159,6 @@ existente. Um controlador do Kubernetes preenche outros campos, como por exemplo a anotação `kubernetes.io/service-account.uid` e a chave `token` no campo `data` com o conteúdo do token. - O exemplo de configuração abaixo declara um Secret de token de service account: ```yaml @@ -294,36 +175,15 @@ data: extra: YmFyCg== ``` - - Ao criar um {{< glossary_tooltip text="Pod" term_id="pod" >}}, o Kubernetes automaticamente cria um Secret de service account e automaticamente atualiza o seu Pod para utilizar este Secret. O Secret de token de service account contém credenciais para acessar a API. - - A criação automática e o uso de credenciais de API podem ser desativados se desejado. Porém, se tudo que você necessita é poder acessar o servidor da API de forma segura, este é o processo recomendado. - - Veja a documentação de [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) para mais informações sobre o funcionamento de service accounts. Você pode @@ -333,39 +193,18 @@ para mais informações sobre como referenciar service accounts em Pods. ### Secrets de configuração do Docker - - Você pode utilizar um dos tipos abaixo para criar um Secret que armazena credenciais para accesso a um registro de contêineres compatível com Docker para busca de imagens: - `kubernetes.io/dockercfg` - `kubernetes.io/dockerconfigjson` - O tipo `kubernetes.io/dockercfg` é reservado para armazenamento de um arquivo `~/.dockercfg` serializado. Este arquivo é o formato legado para configuração do utilitário de linha de comando do Docker. Ao utilizar este tipo de Secret, é preciso garantir que o campo `data` contém uma chave `.dockercfg` cujo valor é o conteúdo do arquivo `~/.dockercfg` codificado no formato base64. - - O tipo `kubernetes.io/dockerconfigjson` foi projetado para armazenamento de um conteúdo JSON serializado que obedece às mesmas regras de formato que o arquivo `~/.docker/config.json`. Este arquivo é um formato mais moderno para o conteúdo @@ -373,8 +212,6 @@ do arquivo `~/.dockercfg`. Ao utilizar este tipo de Secret, o conteúdo do campo `data` deve conter uma chave `.dockerconfigjson` em que o conteúdo do arquivo `~/.docker/config.json` é fornecido codificado no formato base64. - - Um exemplo de um Secret do tipo `kubernetes.io/dockercfg`: ```yaml apiVersion: v1 @@ -387,35 +224,16 @@ data: "" ``` - - {{< note >}} Se você não desejar fazer a codificação em formato base64, você pode utilizar o campo `stringData` como alternativa. {{< /note >}} - - Ao criar estes tipos de Secret utilizando um manifesto (arquivo YAML), o servidor da API verifica se a chave esperada existe no campo `data` e se o valor fornecido pode ser interpretado como um conteúdo JSON válido. O servidor da API não verifica se o conteúdo informado é realmente um arquivo de configuração do Docker. - - Quando você não tem um arquivo de configuração do Docker, ou quer utilizar o comando `kubectl` para criar um Secret de registro de contêineres compatível com o Docker, você pode executar: @@ -427,13 +245,6 @@ kubectl create secret docker-registry secret-tiger-docker \ --docker-server=my-registry.example:5000 ``` - - Esse comando cria um secret do tipo `kubernetes.io/dockerconfigjson`, cujo conteúdo é semelhante ao exemplo abaixo: @@ -474,29 +285,12 @@ que é uma configuração válida do Docker criada automaticamente: ### Secret de autenticação básica - - O tipo `kubernetes.io/basic-auth` é fornecido para armazenar credenciais necessárias para autenticação básica. Ao utilizar este tipo de Secret, o campo `data` do Secret deve conter as duas chaves abaixo: - `username`: o usuário utilizado para autenticação; - `password`: a senha ou token para autenticação. - - Ambos os valores para estas duas chaves são textos codificados em formato base64. Você pode fornecer os valores como texto simples utilizando o campo `stringData` na criação do Secret. @@ -514,14 +308,6 @@ stringData: password: t0p-Secret ``` - - O tipo de autenticação básica é fornecido unicamente por conveniência. Você pode criar um Secret do tipo `Opaque` utilizado para autenticação básica. No entanto, utilizar o tipo embutido de Secret auxilia a unificação dos formatos das suas @@ -530,15 +316,6 @@ requeridas pelo servidor da API. ### Secret de autenticação SSH - - O tipo embutido `kubernetes.io/ssh-auth` é fornecido para armazenamento de dados utilizados em autenticação SSH. Ao utilizar este tipo de Secret, você deve especificar um par de chave-valor `ssh-privatekey` no campo `data` ou no campo @@ -558,29 +335,12 @@ data: MIIEpQIBAAKCAQEAulqb/Y ... ``` - - O Secret de autenticação SSH é fornecido apenas para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credentials utilizadas para autenticação SSH. No entanto, a utilização do tipo embutido auxilia na unificação dos formatos das suas credenciais e o servidor da API fornece verificação dos campos requeridos em uma configuração de Secret. - - {{< caution >}} Chaves privadas SSH não estabelecem, por si só, uma comunicação confiável entre um cliente SSH e um servidor. Uma forma secundária de estabelecer @@ -590,18 +350,6 @@ por exemplo um arquivo `known_hosts` adicionado a um ConfigMap. ### Secrets TLS - - O Kubernetes fornece o tipo embutido de Secret `kubernetes.io/tls` para armazenamento de um certificado e sua chave associada que são tipicamente utilizados para TLS. Estes dados são utilizados primariamente para a @@ -626,16 +374,6 @@ data: MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... ``` - - O tipo TLS é fornecido para a conveniência do usuário. Você pode criar um Secret do tipo `Opaque` para credenciais utilizadas para o servidor e/ou cliente TLS. No entanto, a utilização do tipo embutido auxilia a manter a @@ -650,16 +388,6 @@ kubectl create secret tls my-tls-secret \ --key=path/to/key/file ``` - - O par de chaves pública/privada deve ser criado separadamente. O certificado de chave pública a ser utilizado no argumento `--cert` deve ser codificado em formato .PEM (formato DER codificado em texto base64) e deve corresponder à @@ -671,20 +399,6 @@ certificado) *não* são incluídas. ### Secret de token de autoinicialização {#bootstrap-token-secrets} - - Um Secret de token de autoinicialização pode ser criado especificando o tipo de um Secret explicitamente com o valor `bootstrap.kubernetes.io/token`. Este tipo de Secret é projetado para tokens utilizados durante o processo de inicialização @@ -713,24 +427,6 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` - - Um Secret do tipo token de autoinicialização possui as seguintes chaves no campo `data`: - `token-id`: Uma string com 6 caracteres aleatórios como identificador do @@ -772,14 +468,6 @@ stringData: ## Criando um Secret - - Há várias formas diferentes de criar um Secret: - [criar um Secret utilizando o comando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - [criar um Secret a partir de um arquivo de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) @@ -787,16 +475,11 @@ Há várias formas diferentes de criar um Secret: ## Editando um Secret - Um Secret existente no cluster pode ser editado com o seguinte comando: ```shell kubectl edit secrets mysecret ``` - - Este comando abrirá o editor padrão configurado e permitirá a modificação dos valores codificados em base64 no campo `data`: ```yaml @@ -822,15 +505,6 @@ type: Opaque ## Utilizando Secrets - - Secrets podem ser montados como volumes de dados ou expostos como {{< glossary_tooltip text="variáveis de ambiente" term_id="container-env-variables" >}} para serem utilizados num container de um Pod. Secrets também podem ser @@ -840,17 +514,6 @@ utilizar para interagir com sistemas externos no lugar do usuário. ### Utilizando Secrets como arquivos em um Pod {#using-secrets-as-files-from-a-pod} - - Para consumir um Secret em um volume em um Pod: 1. Crie um Secret ou utilize um previamente existente. Múltiplos Pods podem referenciar o mesmo secret. @@ -887,15 +550,6 @@ spec: secretName: mysecret ``` - - Cada Secret que você deseja utilizar deve ser referenciado na lista `.spec.volumes`. @@ -908,10 +562,6 @@ distintos, o que for mais conveniente. #### Projeção de chaves de Secrets a caminhos específicos - Você pode também controlar os caminhos dentro do volume onde as chaves do Secret são projetadas. Você pode utilizar o campo `.spec.volumes[].secret.items` para mudar o caminho de destino de cada chave: @@ -938,17 +588,6 @@ spec: path: my-group/my-username ``` - - Neste caso: * O valor da chave `username` é armazenado no arquivo `/etc/foo/my-group/my-username` ao invés de `/etc/foo/username`. @@ -961,14 +600,6 @@ existir no Secret correspondente. Caso contrário, o volume não é criado. #### Permissões de arquivos de Secret - - Você pode trocar os bits de permissão de uma chave avulsa de Secret. Se nenhuma permissão for especificada, `0644` é utilizado por padrão. Você pode também especificar uma permissão padrão para o volume inteiro de @@ -994,20 +625,6 @@ spec: defaultMode: 0400 ``` - - Dessa forma, o Secret será montado em `/etc/foo` e todos os arquivos criados no volume terão a permissão `0400`. @@ -1027,7 +644,6 @@ cd /etc/foo ls -l ``` - O resultado é semelhante ao abaixo: ``` total 0 @@ -1035,14 +651,12 @@ lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username ``` - Siga o vínculo simbólico para encontrar a permissão correta do arquivo. ``` cd /etc/foo/..data ls -l ``` - O resultado é semelhante ao abaixo: ``` total 8 @@ -1050,11 +664,6 @@ total 8 -r-------- 1 root root 5 May 18 00:18 username ``` - - Você pode também utilizar mapeamento, como no exemplo anterior, e especificar permissões diferentes para arquivos diferentes conforme abaixo: ```yaml @@ -1079,15 +688,6 @@ spec: mode: 0777 ``` - - Neste caso, o arquivo resultante em `/etc/foo/my-group/my-username` terá as permissões `0777`. Se você utilizar JSON, devido às limitações do formato, você precisará informar as permissões em base decimal, ou o valor `511` neste @@ -1098,12 +698,6 @@ ler essa informação posteriormente. #### Consumindo valores de Secrets em volumes - - Dentro do contêiner que monta um volume de Secret, as chaves deste Secret aparecem como arquivos e os valores dos Secrets são decodificados do formato base64 e armazenados dentro destes arquivos. Ao executar comandos dentro do @@ -1113,7 +707,6 @@ contêiner do exemplo anterior, obteremos os seguintes resultados: ls /etc/foo ``` - O resultado é semelhante a: ``` username @@ -1124,7 +717,6 @@ password cat /etc/foo/username ``` - O resultado é semelhante a: ``` admin @@ -1134,36 +726,16 @@ admin cat /etc/foo/password ``` - O resultado é semelhante a: ``` 1f2d1e2e67df ``` - - A aplicação rodando dentro do contêiner é responsável pela leitura dos Secrets dentro dos arquivos. #### Secrets montados são atualizados automaticamente - - Quando um Secret que está sendo consumido a partir de um volume é atualizado, as chaves projetadas são atualizadas após algum tempo também. O kubelet verifica se o Secret montado está atualizado a cada sincronização periódica. No entanto, @@ -1182,14 +754,6 @@ propagação do cache, onde o tempo de propagação do cache depende do tipo de cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação do _watch_, TTL do cache, ou zero, de acordo com cada um dos tipos de cache. - - {{< note >}} Um contêiner que utiliza Secrets através de um ponto de montagem com a propriedade @@ -1199,17 +763,6 @@ deste Secret. ### Utilizando Secrets como variáveis de ambiente {#using-secrets-as-environment-variables} - - Para utilizar um secret em uma {{< glossary_tooltip text="variável de ambiente" term_id="container-env-variables" >}} em um Pod: @@ -1250,12 +803,6 @@ spec: #### Consumindo valores de Secret em variáveis de ambiente - - Dentro de um contêiner que consome um Secret em variáveis de ambiente, a chave do Secret aparece como uma variável de ambiente comum, contendo os dados do Secret decodificados do formato base64. Ao executar comandos no contêiner do @@ -1265,7 +812,6 @@ exemplo anterior, obteremos os resultados abaixo: echo $SECRET_USERNAME ``` - O resultado é semelhante a: ``` @@ -1275,7 +821,7 @@ admin ```shell echo $SECRET_PASSWORD ``` - + O resultado é semelhante a: ``` @@ -1284,11 +830,6 @@ O resultado é semelhante a: #### Variáveis de ambiente não são atualizadas após uma atualização no Secret - - Se um contêiner já consome um Secret em uma variável de ambiente, uma atualização dos valores do Secret não será refletida no contêiner a menos que o contêiner seja reiniciado. @@ -1299,16 +840,6 @@ quando Secrets são atualizados. {{< feature-state for_k8s_version="v1.21" state="stable" >}} - - A funcionalidade do Kubernetes _Secrets e ConfigMaps imutáveis_ fornece uma opção para marcar Secrets e ConfigMaps individuais como imutáveis. Em clusters que fazem uso extensivo de Secrets (pelo menos dezenas de milhares de montagens @@ -1320,13 +851,6 @@ disrupções na execução de aplicações; no kube-apiserver, devido ao fechamento de _watches_ de Secrets marcados como imutáveis. - - Esta funcionalidade é controlada pelo [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ImmutableEphemeralVolumes`, que está habilitado por padrão desde a versão @@ -1342,15 +866,6 @@ data: immutable: true ``` - - {{< note >}} Uma vez que um Secret ou ConfigMap seja marcado como imutável, _não_ é mais possível reverter esta mudança, nem alterar os conteúdos do campo `data`. Você @@ -1360,13 +875,6 @@ montagem referenciando o Secret removido - é recomendado recriar tais Pods. ### Usando `imagePullSecrets` {#using-imagepullsecrets} - - O campo `imagePullSecrets` é uma lista de referências para Secrets no mesmo namespace. Você pode utilizar a lista `imagePullSecrets` para enviar Secrets que contém uma senha para acesso a um registro de contêineres do Docker (ou @@ -1377,24 +885,11 @@ para maiores detalhes sobre o campo `imagePullSecrets`. #### Especificando `imagePullSecrets` manualmente - - Você pode ler sobre como especificar `imagePullSecrets` em um Pod na [documentação de imagens de contêiner](/pt-br/docs/concepts/containers/images/#especificando-imagepullsecrets-em-um-pod). ### Configurando `imagePullSecrets` para serem vinculados automaticamente - - Você pode criar manualmente `imagePullSecrets` e referenciá-los em uma ServiceAccount. Quaisquer Pods criados com esta ServiceAccount, especificada explicitamente ou por padrão, têm o campo `imagePullSecrets` populado com os @@ -1406,48 +901,19 @@ para uma explicação detalhada do processo. ### Restrições - - Referências a Secrets em volumes são validadas para garantir que o objeto especificado realmente existe e é um objeto do tipo Secret. Portanto, um Secret precisa ser criado antes de quaisquer Pods que dependam deste. - - Objetos Secret residem em um {{< glossary_tooltip text="namespace" term_id="namespace" >}}. Secrets podem ser referenciados somente por Pods no mesmo namespace. - - Secrets individuais são limitados ao tamanho de 1MiB. Esta limitação ter por objetivo desencorajar a criação de Secrets muito grandes que poderiam exaurir a memória do servidor da API e do kubelet. No entanto, a criação de muitos Secrets pequenos também pode exaurir a memória. Limites mais completos de uso de memória em função de Secrets é uma funcionalidade prevista para o futuro. - - O kubelet suporta apenas o uso de Secrets em Pods onde os Secrets são obtidos do servidor da API. Isso inclui quaisquer Pods criados usando o comando `kubectl`, ou indiretamente através de um controlador de replicação, mas não @@ -1456,33 +922,13 @@ kubelet, ou a sua API REST (estas são formas incomuns de criar um Pod). A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} não pode se referir a um Secret ou a qualquer outro objeto da API. - - Secrets precisam ser criados antes de serem consumidos em Pods como variáveis de ambiente, exceto quando são marcados como opcionais. Referências a Secrets que não existem provocam falhas na inicialização do Pod. - - Referências (campo `secretKeyRef`) a chaves que não existem em um Secret nomeado provocam falhas na inicialização do Pod. - - Secrets utilizados para popular variáveis de ambiente através do campo `envFrom` que contém chaves inválidas para utilização como nome de uma variável de ambiente terão tais chaves ignoradas. O Pod inicializará normalmente. Porém, um evento @@ -1495,7 +941,6 @@ refere ao Secret default/mysecret, contendo duas chaves inválidas: `1badkey` e kubectl get events ``` - O resultado é semelhante a: ``` @@ -1505,17 +950,6 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT ### Interações do ciclo de vida entre Secrets e Pods - - Quando um Pod é criado através de chamadas à API do Kubernetes, não há validação da existência de um Secret referenciado. Uma vez que um Pod seja agendado, o kubelet tentará buscar o valor do Secret. Se o Secret não puder ser encontrado @@ -1530,7 +964,6 @@ do Pod irá iniciar até que todos os volumes estejam montados. ### Caso de uso: Como variáveis de ambiente em um contêiner - Crie um manifesto de Secret ```yaml @@ -1544,16 +977,12 @@ data: PASSWORD: MWYyZDFlMmU2N2Rm ``` - Crie o Secret no seu cluster: ```shell kubectl apply -f mysecret.yaml ``` - Utilize `envFrom` para definir todos os dados do Secret como variáveis de ambiente do contêiner. Cada chave do Secret se torna o nome de uma variável de ambiente no Pod. @@ -1576,31 +1005,18 @@ spec: ### Caso de uso: Pod com chaves SSH - Crie um Secret contendo chaves SSH: ```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 ``` - O resultado é semelhante a: ``` secret "ssh-key-secret" created ``` - - Você também pode criar um manifesto `kustomization.yaml` com um campo `secretGenerator` contendo chaves SSH. @@ -1636,7 +1052,6 @@ spec: mountPath: "/etc/secret-volume" ``` - Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: ``` @@ -1644,24 +1059,11 @@ Ao rodar o comando do contêiner, as partes da chave estarão disponíveis em: /etc/secret-volume/ssh-privatekey ``` - - O contêiner então pode utilizar os dados do secret para estabelecer uma conexão SSH. ### Caso de uso: Pods com credenciais de ambientes de produção ou testes - - Este exemplo ilustra um Pod que consome um Secret contendo credenciais de um ambiente de produção e outro Pod que consome um Secret contendo credenciais de um ambiente de testes. @@ -1673,43 +1075,24 @@ rodar `kubectl create secret`. kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` - O resultado é semelhante a: ``` secret "prod-db-secret" created ``` - Você pode também criar um Secret com credenciais para o ambiente de testes. ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` - O resultado é semelhante a: ``` secret "test-db-secret" created ``` - - {{< note >}} Caracteres especiais como `$`, `\`, `*`, `+` e `!` serão interpretados pelo seu [shell](https://pt.wikipedia.org/wiki/Shell_(computa%C3%A7%C3%A3o)) e precisam de @@ -1772,7 +1155,6 @@ items: EOF ``` - Adicione os Pods a um manifesto `kustomization.yaml`: ```shell @@ -1782,17 +1164,12 @@ resources: EOF ``` - Crie todos estes objetos no servidor da API rodando o comando: ```shell kubectl apply -k . ``` - - Ambos os contêineres terão os seguintes arquivos presentes nos seus sistemas de arquivos, com valores para cada um dos ambientes dos contêineres: @@ -1801,18 +1178,6 @@ arquivos, com valores para cada um dos ambientes dos contêineres: /etc/secret-volume/password ``` - - Observe como as `spec`s para cada um dos Pods diverge somente em um campo. Isso facilita a criação de Pods com capacidades diferentes a partir de um template mais genérico. @@ -1841,12 +1206,6 @@ spec: ### Caso de uso: _dotfiles_ em um volume de Secret - - Você pode fazer com que seus dados fiquem "ocultos" definindo uma chave que se inicia com um ponto (`.`). Este tipo de chave representa um _dotfile_, ou arquivo "oculto". Por exemplo, quando o Secret abaixo é montado em um volume, @@ -1882,17 +1241,6 @@ spec: mountPath: "/etc/secret-volume" ``` - - Este volume irá conter um único arquivo, chamado `.secret-file`, e o contêiner `dotfile-test-container` terá este arquivo presente no caminho `/etc/secret-volume/.secret-file`. @@ -1905,22 +1253,6 @@ conteúdo de um diretório. ### Caso de uso: Secret visível somente em um dos contêineres de um pod {#use-case-secret-visible-to-one-container-in-a-pod} - - Suponha que um programa necessita manipular requisições HTTP, executar regras de negócio complexas e então assinar mensagens com HMAC. Devido à natureza complexa da aplicação, pode haver um _exploit_ despercebido que lê arquivos @@ -1942,39 +1274,16 @@ apenas ler um arquivo presente no disco. ### Clientes que utilizam a API de Secrets - - Ao instalar aplicações que interajam com a API de Secrets, você deve limitar o acesso utilizando [políticas de autorização](/docs/reference/access-authn-authz/authorization/) como [RBAC](/docs/reference/access-authn-authz/rbac/). - - Secrets frequentemente contém valores com um espectro de importância, muitos dos quais podem causar escalações dentro do Kubernetes (por exemplo, tokens de service account) e de sistemas externos. Mesmo que um aplicativo individual possa avaliar o poder do Secret com o qual espera interagir, outras aplicações dentro do mesmo namespace podem tornar estas suposições inválidas. - - Por estas razões, as requisições `watch` (observar) e `list` (listar) de Secrets dentro de um namespace são permissões extremamente poderosas e devem ser evitadas, pois a listagem de Secrets permite a clientes inspecionar os @@ -1982,27 +1291,12 @@ valores de todos os Secrets presentes naquele namespace. A habilidade de listar e observar todos os Secrets em um cluster deve ser reservada somente para os componentes mais privilegiados, que fazem parte do nível de aplicações de sistema. - - Aplicações que necessitam acessar a API de Secret devem realizar uma requisição `get` nos Secrets que precisam. Isto permite que administradores restrinjam o acesso a todos os Secrets, enquanto [utilizam uma lista de autorização a instâncias individuais](/docs/reference/access-authn-authz/rbac/#referring-to-resources) que a aplicação precise. - - Para melhor desempenho em uma requisição `get` repetitiva, clientes podem criar objetos que referenciam o Secret e então utilizar a requisição `watch` neste novo objeto, requisitando o Secret novamente quando a referência mudar. @@ -2014,95 +1308,37 @@ provavelmente estará disponível em versões futuras do Kubernetes. ### Proteções - - Como Secrets podem ser criados de forma independente de Pods que os utilizam, há menos risco de um Secret ser exposto durante o fluxo de trabalho de criação, visualização, e edição de Pods. O sistema pode também tomar precauções adicionais com Secrets, como por exemplo evitar que sejam escritos em disco quando possível. - - Um Secret só é enviado para um nó se um Pod naquele nó requerê-lo. O kubelet armazena o Secret num sistema de arquivos `tmpfs`, de forma a evitar que o Secret seja escrito em armazenamento persistente. Uma vez que o Pod que depende do Secret é removido, o kubelet apaga sua cópia local do Secret também. - - Secrets de vários Pods diferentes podem existir no mesmo nó. No entanto, somente os Secrets que um Pod requerer estão potencialmente visíveis em seus contêineres. Portanto, um Pod não tem acesso aos Secrets de outro Pod. - - Um Pod pode conter vários contêineres. Porém, cada contêiner em um Pod precisa requerer o volume de Secret nos seus `volumeMounts` para que este fique visível dentro do contêiner. Esta característica pode ser utilizada para construir [partições de segurança ao nível do Pod](#use-case-secret-visible-to-one-container-in-a-pod). - - Na maioria das distribuições do Kubernetes, a comunicação entre usuários e o servidor da API e entre servidor da API e os kubelets é protegida por SSL/TLS. Secrets são protegidos quando transmitidos através destes canais. {{< feature-state for_k8s_version="v1.13" state="beta" >}} - - Você pode habilitar [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/) em dados de Secret para evitar que estes sejam armazenados em texto plano no {{< glossary_tooltip term_id="etcd" >}}. ### Riscos - - - No servidor da API, os dados de Secret são armazenados no {{< glossary_tooltip term_id="etcd" >}}; portanto: - Administradores devem habilitar encriptação em disco para dados do cluster @@ -2128,13 +1364,6 @@ em dados de Secret para evitar que estes sejam armazenados em texto plano no ## {{% heading "whatsnext" %}} - - - Aprenda a [gerenciar Secrets utilizando `kubectl`](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - Aprenda a [gerenciar Secrets utilizando arquivos de configuração](/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Aprenda a [gerenciar Secrets utilizando kustomize](/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize/) From 6708e86c6e574f3c867debf9d58d1fc072d2f0a7 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Thu, 6 Jan 2022 19:33:47 -0500 Subject: [PATCH 089/145] Remove comment blocks with original content. --- .../docs/concepts/configuration/secret.md | 21 ------------------- 1 file changed, 21 deletions(-) diff --git a/content/pt-br/docs/concepts/configuration/secret.md b/content/pt-br/docs/concepts/configuration/secret.md index 1638aa4faf..bd0cd7315d 100644 --- a/content/pt-br/docs/concepts/configuration/secret.md +++ b/content/pt-br/docs/concepts/configuration/secret.md @@ -9,29 +9,8 @@ feature: weight: 30 --- - - - - Um Secret é um objeto que contém uma pequena quantidade de informação sensível, como senhas, tokens ou chaves. Este tipo de informação poderia, em outras circunstâncias, ser colocada diretamente em uma configuração de From 2546d6439738cd6df3dfd9d30612ee3d5e3fad48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Wed, 5 Jan 2022 22:42:59 +0800 Subject: [PATCH 090/145] [zh] synchronize translate check-if-dockershim-deprecation-affects-you.md --- ...k-if-dockershim-deprecation-affects-you.md | 35 ++++++++++++------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md index c1cf73c96e..bb77882ad1 100644 --- a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md +++ b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you.md @@ -52,35 +52,44 @@ dependency on Docker: 当用了替代的容器运行时之后，Docker 命令可能不工作，甚至产生意外的输出。 这才是判定你是否依赖于 Docker 的方法。 - -1. 确认没有特权 Pod 执行 docker 命令。 -2. 检查 Kubernetes 基础架构外部节点上的脚本和应用，确认它们没有执行 Docker 命令。可能的命令有： +--> +1. 确认没有特权 Pod 执行 Docker 命令（如 `docker ps`）、重新启动 Docker + 服务（如 `systemctl restart docker.service`）或修改 + Docker 配置文件 `/etc/docker/daemon.json`。 +2. 检查 Docker 配置文件（如 `/etc/docker/daemon.json`）中容器镜像仓库的镜像（mirror）站点设置。 + 这些配置通常需要针对不同容器运行时来重新设置。 +3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行Docker命令。 + 可能的情况如： - SSH 到节点排查故障； - 节点启动脚本； - - 直接安装在节点上的监视和安全代理。 -3. 检查执行了上述特权操作的第三方工具。详细操作请参考: - [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) -4. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 + - 直接安装在节点上的监控和安全代理。 +4. 检查执行上述特权操作的第三方工具。详细操作请参考： + [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) +5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具，需要在迁移之前，在测试集群上完成功能验证。 - From 875bb06af84d9d485072454bbd3531aaf9780acc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B8=85=E8=BF=9B=E8=B6=85?= Date: Wed, 5 Jan 2022 22:56:12 +0800 Subject: [PATCH 091/145] [zh] synchronize translate encrypt-data.md --- content/zh/docs/tasks/administer-cluster/encrypt-data.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/encrypt-data.md b/content/zh/docs/tasks/administer-cluster/encrypt-data.md index 2b62f86725..c63032ca4d 100644 --- a/content/zh/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/zh/docs/tasks/administer-cluster/encrypt-data.md @@ -107,9 +107,9 @@ read that resource will fail until it is deleted or a valid decryption key is pr Name | Encryption | Strength | Speed | Key Length | Other Considerations -----|------------|----------|-------|------------|--------------------- `identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written. -`aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`. `secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review. `aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented. +`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks. `kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/) Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider @@ -119,9 +119,9 @@ is the first provider, the first key is used for encryption. 名称 | 加密类型 | 强度 | 速度 | 密钥长度 | 其它事项 -----|------------|----------|-------|------------|--------------------- `identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时，资源将在新值写入时被解密。 -`aescbc` | 填充 PKCS#7 的 AES-CBC | 最强 | 快 | 32字节 | 建议使用的加密项，但可能比 `secretbox` 稍微慢一些。 `secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准，在需要高度评审的环境中可能不被接受。 `aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。 +`aescbc` | 填充 PKCS#7 的 AES-CBC | 弱 | 快 | 32字节 | 由于 CBC 容易受到密文填塞攻击（Padding Oracle Attack），不推荐使用。 `kms` | 使用信封加密方案：数据使用带有 PKCS#7 填充的 AES-CBC 通过数据加密密钥（DEK）加密，DEK 根据 Key Management Service（KMS）中的配置通过密钥加密密钥（Key Encryption Keys，KEK）加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK，并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/zh/docs/tasks/administer-cluster/kms-provider/) 每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。 From 21558d676a2c9dbe41af92c7e122ed55ae947829 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 7 Jan 2022 21:10:41 +0800 Subject: [PATCH 092/145] [zh] Translate find out runtime page --- .../find-out-runtime-you-use.md | 83 +++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md diff --git a/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md new file mode 100644 index 0000000000..7a6f3c8df9 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -0,0 +1,83 @@ +--- +title: 查明节点上所使用的容器运行时 +content_type: task +weight: 10 +--- + + + + + +本页面描述查明集群中节点所使用的[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) +的步骤。 + + +取决于你运行集群的方式，节点所使用的容器运行时可能是事先配置好的， +也可能需要你来配置。如果你在使用托管的 Kubernetes 服务， +可能存在特定于厂商的方法来检查节点上配置的容器运行时。 +本页描述的方法应该在能够执行 `kubectl` 的场合下都可以工作。 + +## {{% heading "prerequisites" %}} + + +安装并配置 `kubectl`。参见[安装工具](/zh/docs/tasks/tools/#kubectl) 节了解详情。 + + +## 查明节点所使用的容器运行时 + +使用 `kubectl` 来读取并显示节点信息： + +```shell +kubectl get nodes -o wide +``` + + +输出如下面所示。`CONTAINER-RUNTIME` 列给出容器运行时及其版本。 + +```none +# For dockershim +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.16.15 docker://19.3.1 +node-2 Ready v1.16.15 docker://19.3.1 +node-3 Ready v1.16.15 docker://19.3.1 +``` + +```none +# For containerd +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.19.6 containerd://1.4.1 +node-2 Ready v1.19.6 containerd://1.4.1 +node-3 Ready v1.19.6 containerd://1.4.1 +``` + + +你可以在[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) +页面找到与容器运行时相关的更多信息。 + From 4bb3f367a261293e7044ff169a93f3a91d1bec82 Mon Sep 17 00:00:00 2001 From: Priyanka Saggu Date: Wed, 5 Jan 2022 13:46:16 +0530 Subject: [PATCH 093/145] blog: meet our contributors APAC India region --- ...t-our-contributors-APAC-India-region-01.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md diff --git a/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md new file mode 100644 index 0000000000..4c969ff50c --- /dev/null +++ b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md @@ -0,0 +1,106 @@ +--- +layout: blog +title: "Meet Our Contributors - APAC (India region)" +date: 2022-01-10T12:00:00+0000 +slug: meet-our-contributors-india-ep-01 +canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/ +--- + +**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) + +**Editor:** [Priyanka Saggu](https://psaggu.com) + +--- + +Good day, everyone 👋 + +Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series. + + +In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives. + +💫 *Let's get started, so without further ado…* + + +## [Arsh Sharma](https://github.com/RinkiyaKeDad) + +Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project. + +He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture. + +To the newcomers, Arsh helps plan their early contributions sustainably. + +> _I would encourage folks to contribute in a way that's sustainable. What I mean by that +> is that it's easy to be very enthusiastic early on and take up more stuff than one can +> actually handle. This can often lead to burnout in later stages. It's much more sustainable +> to work on things iteratively._ + +## [Kunal Kushwaha](https://github.com/kunal-kushwaha) + +Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle. + +At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. + +As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer. + + +> _I believe if you find yourself in a place where you do not know much about the +> project, that's a good thing because now you can learn while contributing and the +> community is there to help you. It has helped me a lot in gaining skills, meeting +> people from around the world and also helping them. You can learn on the go, +> you don't have to be an expert. Make sure to also check out no code contributions +> because being a beginner is a skill and you can bring new perspectives to the +> organisation._ + +## [Madhav Jivarajani](https://github.com/MadhavJivrajani) + + +Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience). + +Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129). + +In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc). + +> _I initially did not know much about Kubernetes. I joined because the community was +> super friendly. But what made me stay was not just the people, but the project itself. +> My solution to not feeling overwhelmed in the community was to gain as much context +> and knowledge into the topics that I was interested in and were being discussed. And +> as a result I continued to dig deeper into Kubernetes and the design of it. +> I am a systems nut & thus Kubernetes was an absolute goldmine for me._ + + +## [Rajas Kakodkar](https://github.com/rajaskakodkar) + +Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019. + +He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects. + +One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem. + +> _I enjoy contributing to Kubernetes not just because I get to work on +> cutting edge tech but more importantly because I get to work with +> awesome people and help in solving real world problems._ + +## [Rajula Vineet Reddy](https://github.com/rajula96reddy) + +Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles. + +He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject. + +According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community. + +> _I find the community very helpful and it's always_ +> “you get back as much as you contribute”. +> _The more involved you are, the more you will understand, get to learn and +> contribute new things._ +> +> _The first step to_ “come forward and start” _is hard. But it's all gonna be +> smooth after that. Just take that jump._ + +--- + +If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated. + + +We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 + From cb7da4fc41aad0cdaf70a893d1bed095d1990475 Mon Sep 17 00:00:00 2001 From: k0000k <84006880+k0000k@users.noreply.github.com> Date: Sat, 8 Jan 2022 17:10:47 +0900 Subject: [PATCH 094/145] [ko] Add translation of parts that haven't been translated in _index file --- content/ko/_index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index c6350f1559..34cdfe5740 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -39,8 +39,8 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}

150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는 도전

-

By Sarah Wells, Technical Director for Operations and Reliability, Financial Times

- +

Sarah Wells, Financial Times 운영 및 안정성 기술 담당 이사

+

Attend KubeCon North America on October 11-15, 2021 From 5473fe272f20cf5d52b2cebb6918c44f7a149700 Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Sat, 8 Jan 2022 15:20:14 +0200 Subject: [PATCH 095/145] Remove Unknown Symbol on Container Runtime Interface (CRI) Page --- .../en/docs/reference/glossary/container-runtime-interface.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/glossary/container-runtime-interface.md b/content/en/docs/reference/glossary/container-runtime-interface.md index 11f7bc50f4..28a67cbbb4 100644 --- a/content/en/docs/reference/glossary/container-runtime-interface.md +++ b/content/en/docs/reference/glossary/container-runtime-interface.md @@ -19,4 +19,4 @@ The Kubernetes Container Runtime Interface (CRI) defines the main [gRPC](https://grpc.io) protocol for the communication between the [cluster components](/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and -{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. From 09fa80f5066fb6c3f470fca270510bd7de6e4639 Mon Sep 17 00:00:00 2001 From: ptux Date: Sat, 8 Jan 2022 22:43:39 +0900 Subject: [PATCH 096/145] done --- .../migrating-from-dockershim/_index.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md new file mode 100644 index 0000000000..44d7037b2d --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -0,0 +1,18 @@ +--- +title: dockershimからの移行 +weight: 10 +content_type: task +--- + + + +dockershimから他のコンテナランタイムに移行する際に知っておくべき情報を紹介します。 + +Kubernetes 1.20で[dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 + +この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 + +dockershimから代替のコンテナランタイムに移行することが推奨されます。 +コンテナランタイム](/docs/setup/production-environment/container-runtimes/) のセクションをチェックして、オプションを確認してください。 +問題が発生した場合は、必ず[問題の報告](https://github.com/kubernetes/kubernetes/issues)をしてください。 +そうすれば、問題が適時に修正され、クラスタがdockershimの削除に対応できるようになります。 From 95211a8fcf1f6e5178cc84ab0086ff0d1010281b Mon Sep 17 00:00:00 2001 From: ptux Date: Sun, 9 Jan 2022 08:48:10 +0900 Subject: [PATCH 097/145] change back --- .../migrating-from-dockershim/_index.md | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md deleted file mode 100644 index 44d7037b2d..0000000000 --- a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: dockershimからの移行 -weight: 10 -content_type: task ---- - - - -dockershimから他のコンテナランタイムに移行する際に知っておくべき情報を紹介します。 - -Kubernetes 1.20で[dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 - -この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 - -dockershimから代替のコンテナランタイムに移行することが推奨されます。 -コンテナランタイム](/docs/setup/production-environment/container-runtimes/) のセクションをチェックして、オプションを確認してください。 -問題が発生した場合は、必ず[問題の報告](https://github.com/kubernetes/kubernetes/issues)をしてください。 -そうすれば、問題が適時に修正され、クラスタがdockershimの削除に対応できるようになります。 From 215983779b5722710511d00a0d9623e7e8c1c8db Mon Sep 17 00:00:00 2001 From: ptux Date: Sun, 9 Jan 2022 08:55:01 +0900 Subject: [PATCH 098/145] down --- .../find-out-runtime-you-use.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md new file mode 100644 index 0000000000..7d6b6f1fd0 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -0,0 +1,44 @@ +--- +title: ノードで使用されているコンテナランタイムの確認 +content_type: task +weight: 10 +--- + + + +このページでは、クラスター内のノードが使用している[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)を確認する手順を概説しています。 +クラスターの実行方法によっては、ノード用のコンテナランタイムが事前に設定されている場合と、設定する必要がある場合があります。 +マネージドKubernetesサービスを使用している場合、ノードに設定されているコンテナランタイムを確認するためのベンダー固有の方法があるかもしれません。 +このページで説明する方法は、`kubectl` の実行が許可されていればいつでも動作するはずです。 + +## {{% heading "prerequisites" %}} + +`kubectl`をインストールし、設定します。詳細は[ツールのインストール](/docs/tasks/tools/#kubectl)の項を参照してください。 + +## ノードで使用されているコンテナランタイムの確認 + +ノードの情報を取得して表示するには`kubectl`を使用します: + +```shell +kubectl get nodes -o wide +``` + +出力は以下のようなものです。列`CONTAINER-RUNTIME`には、ランタイムとそのバージョンが出力されます。 + +```none +# For dockershim +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.16.15 docker://19.3.1 +node-2 Ready v1.16.15 docker://19.3.1 +node-3 Ready v1.16.15 docker://19.3.1 +``` + +```none +# For containerd +NAME STATUS VERSION CONTAINER-RUNTIME +node-1 Ready v1.19.6 containerd://1.4.1 +node-2 Ready v1.19.6 containerd://1.4.1 +node-3 Ready v1.19.6 containerd://1.4.1 +``` + +コンテナランタイムについては、[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)のページで詳細を確認することができます。 From 4a2981a0d84d4c2fdd87513b64ed5b9a399e97d8 Mon Sep 17 00:00:00 2001 From: expoli <31023767+expoli@users.noreply.github.com> Date: Sun, 9 Jan 2022 15:40:57 +0800 Subject: [PATCH 099/145] Correct some misrepresentations on Chinese pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Correct some misrepresentations on Chinese pages # 原始文件内容 原始文档上写的是：输入类似于 （Enter something like），但是者实际上是一个输出内容。 此错误在这个页面上不止一处，已经全部订正 ```bash 输入类似于 -> 输出类似于 input -> output ``` --- content/zh/docs/tutorials/security/ns-level-pss.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/tutorials/security/ns-level-pss.md b/content/zh/docs/tutorials/security/ns-level-pss.md index a141edfb3a..5b579dfc28 100644 --- a/content/zh/docs/tutorials/security/ns-level-pss.md +++ b/content/zh/docs/tutorials/security/ns-level-pss.md @@ -61,7 +61,7 @@ Install the following on your workstation: kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 ``` - 输入类似于： + 输出类似于： ``` Creating cluster "psa-ns-level" ... ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 @@ -84,7 +84,7 @@ Install the following on your workstation: kubectl cluster-info --context kind-psa-ns-level ``` - 输入类似于： + 输出类似于： ``` Kubernetes control plane is running at https://127.0.0.1:50996 CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy @@ -194,7 +194,7 @@ namespace/example created kubectl apply -n default -f /tmp/pss/nginx-pod.yaml ``` - 输入类似于： + 输出类似于： ``` pod/nginx created ``` @@ -240,4 +240,4 @@ Run `kind delete cluster -name psa-ns-level` to delete the cluster created. 4. 创建一个应用以下 Pod 安全标准的新 Pod - [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/) - [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) -- [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/) \ No newline at end of file +- [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/) From 40bd978326fb711f9177ef8c9225920a7442b367 Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 9 Jan 2022 19:20:12 +0900 Subject: [PATCH 100/145] Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../migrating-from-dockershim/find-out-runtime-you-use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md index 7d6b6f1fd0..0e4130c276 100644 --- a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -13,7 +13,7 @@ weight: 10 ## {{% heading "prerequisites" %}} -`kubectl`をインストールし、設定します。詳細は[ツールのインストール](/docs/tasks/tools/#kubectl)の項を参照してください。 +`kubectl`をインストールし、設定します。詳細は[ツールのインストール](/ja/docs/tasks/tools/#kubectl)の項を参照してください。 ## ノードで使用されているコンテナランタイムの確認 From 50aa4ac47e7a7d117a7d5250d0c884da6cbfb4a9 Mon Sep 17 00:00:00 2001 From: Wang Date: Sun, 9 Jan 2022 19:20:17 +0900 Subject: [PATCH 101/145] Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md Co-authored-by: Ryota Yamada <42636694+riita10069@users.noreply.github.com> --- .../migrating-from-dockershim/find-out-runtime-you-use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md index 0e4130c276..63ef19d50a 100644 --- a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -9,7 +9,7 @@ weight: 10 このページでは、クラスター内のノードが使用している[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)を確認する手順を概説しています。 クラスターの実行方法によっては、ノード用のコンテナランタイムが事前に設定されている場合と、設定する必要がある場合があります。 マネージドKubernetesサービスを使用している場合、ノードに設定されているコンテナランタイムを確認するためのベンダー固有の方法があるかもしれません。 -このページで説明する方法は、`kubectl` の実行が許可されていればいつでも動作するはずです。 +このページで説明する方法は、`kubectl`の実行が許可されていればいつでも動作するはずです。 ## {{% heading "prerequisites" %}} From ec94e69c4ef0ea63692c312038f16c8fc2e1b6b7 Mon Sep 17 00:00:00 2001 From: Babapool Date: Fri, 17 Dec 2021 19:44:44 +0530 Subject: [PATCH 102/145] Merge the tutorials under tutorials->clusters into tutorials->security --- content/en/docs/tutorials/_index.md | 9 ++------- content/en/docs/tutorials/clusters/_index.md | 5 ----- .../en/docs/tutorials/{clusters => security}/apparmor.md | 0 .../en/docs/tutorials/{clusters => security}/seccomp.md | 0 static/_redirects | 3 +++ 5 files changed, 5 insertions(+), 12 deletions(-) delete mode 100644 content/en/docs/tutorials/clusters/_index.md rename content/en/docs/tutorials/{clusters => security}/apparmor.md (100%) rename content/en/docs/tutorials/{clusters => security}/seccomp.md (100%) diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 0f1181e2cf..01bb9a6552 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -47,12 +47,6 @@ Before walking through each tutorial, you may want to bookmark the * [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) -## Clusters - -* [AppArmor](/docs/tutorials/clusters/apparmor/) - -* [seccomp](/docs/tutorials/clusters/seccomp/) - ## Services * [Using Source IP](/docs/tutorials/services/source-ip/) @@ -61,7 +55,8 @@ Before walking through each tutorial, you may want to bookmark the * [Apply Pod Security Standards at Cluster level](/docs/tutorials/security/cluster-level-pss/) * [Apply Pod Security Standards at Namespace level](/docs/tutorials/security/ns-level-pss/) - +* [AppArmor](/docs/tutorials/security/apparmor/) +* [seccomp](/docs/tutorials/security/seccomp/) ## {{% heading "whatsnext" %}} If you would like to write a tutorial, see diff --git a/content/en/docs/tutorials/clusters/_index.md b/content/en/docs/tutorials/clusters/_index.md deleted file mode 100644 index 2db6156b6f..0000000000 --- a/content/en/docs/tutorials/clusters/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Clusters" -weight: 60 ---- - diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/security/apparmor.md similarity index 100% rename from content/en/docs/tutorials/clusters/apparmor.md rename to content/en/docs/tutorials/security/apparmor.md diff --git a/content/en/docs/tutorials/clusters/seccomp.md b/content/en/docs/tutorials/security/seccomp.md similarity index 100% rename from content/en/docs/tutorials/clusters/seccomp.md rename to content/en/docs/tutorials/security/seccomp.md diff --git a/static/_redirects b/static/_redirects index 780597c901..f8bea04f7e 100644 --- a/static/_redirects +++ b/static/_redirects @@ -546,3 +546,6 @@ /id/docs/concepts/configuration/pod-overhead/ /id/docs/concepts/scheduling-eviction/pod-overhead/ 301 /pt/* /pt-br/:splat 302! + +/docs/tutorials/clusters/apparmor.md /docs/tutorials/security/apparmor.md 301 +/docs/tutorials/clusters/seccomp.md /docs/tutorials/security/seccomp.md 301 \ No newline at end of file From cb9a103af6e9a74965329b27d9c53a2ce3ad8364 Mon Sep 17 00:00:00 2001 From: Babapool Date: Fri, 17 Dec 2021 23:00:11 +0530 Subject: [PATCH 103/145] Fix the redirect links Co-Authored-By: Tim Bannister --- static/_redirects | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/static/_redirects b/static/_redirects index f8bea04f7e..10e81668ee 100644 --- a/static/_redirects +++ b/static/_redirects @@ -335,6 +335,8 @@ /docs/tutorials/kubernetes-basics/expose-intro/ /docs/tutorials/kubernetes-basics/expose/expose-intro/ 301 /docs/tutorials/kubernetes-basics/scale-interactive/ /docs/tutorials/kubernetes-basics/scale/scale-interactive/ 301 /docs/tutorials/kubernetes-basics/scale-intro/ /docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 +/docs/tutorials/clusters/apparmor/ /docs/tutorials/security/apparmor/ 301 +/docs/tutorials/clusters/seccomp/ /docs/tutorials/security/seccomp/ 301 /ja/docs/tutorials/kubernetes-basics/scale-intro/ /ja/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /ko/docs/tutorials/kubernetes-basics/scale-intro/ /ko/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /docs/tutorials/kubernetes-basics/update-interactive/ /docs/tutorials/kubernetes-basics/update/update-interactive/ 301 @@ -546,6 +548,3 @@ /id/docs/concepts/configuration/pod-overhead/ /id/docs/concepts/scheduling-eviction/pod-overhead/ 301 /pt/* /pt-br/:splat 302! - -/docs/tutorials/clusters/apparmor.md /docs/tutorials/security/apparmor.md 301 -/docs/tutorials/clusters/seccomp.md /docs/tutorials/security/seccomp.md 301 \ No newline at end of file From 58fcd66c8960aec832ba0e52d8696f6145aa0fe7 Mon Sep 17 00:00:00 2001 From: Shannon Kularathna Date: Mon, 10 Jan 2022 07:58:19 +0000 Subject: [PATCH 104/145] Correct minor spelling and grammar issues --- ...kubernetes-is-moving-on-from-dockershim.md | 32 +++++++++++-------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md index 17a38caa5f..07f33b8b80 100644 --- a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md +++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md @@ -9,20 +9,22 @@ slug: kubernetes-is-moving-on-from-dockershim Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited to reaffirm our community values by supporting open source container runtimes, -enable a smaller kubelet, and increase engineering velocity for teams using -Kubernetes. If you [use Docker Engine as a Container Runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) -for your Kubernetes cluster, get ready to migrate to 1.24! To check if you're +enabling a smaller kubelet, and increasing engineering velocity for teams using +Kubernetes. If you [use Docker Engine as a container runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) +for your Kubernetes cluster, get ready to migrate in 1.24! To check if you're affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). ## Why we’re moving away from dockershim Docker was the first container runtime used by Kubernetes. This is one of the reasons why Docker is so familiar to many Kubernetes users and enthusiasts. +Docker support was hardcoded into Kubernetes – a component the project refers to +as dockershim. As containerization became an industry standard, the Kubernetes project added support -for additional runtimes. This culminated with the implementation of the +for additional runtimes. This culminated in the implementation of the container runtime interface (CRI), letting system components (like the kubelet) -talk to container runtimes in a standardized way. As a result, the hardcoded support for Docker – -a component the project refers to as dockershim – became an anomaly in the Kubernetes project. +talk to container runtimes in a standardized way. As a result, dockershim became +an anomaly in the Kubernetes project. Dependencies on Docker and dockershim have crept into various tools and projects in the CNCF ecosystem ecosystem, resulting in fragile code. @@ -33,14 +35,14 @@ Stay tuned for future communications on the topic! ## Deprecation timeline -We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020.  Full removal is targeted +We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020. Full removal is targeted in Kubernetes 1.24, in April 2022. This timeline aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior), which states that deprecated behaviors must function for at least 1 year after their announced deprecation. We'll support Kubernetes version 1.23, which includes -dockershim, for another year in the Kubernetes project. Managed +dockershim, for another year in the Kubernetes project. For managed Kubernetes providers, vendor support is likely to last even longer, but this is dependent on the companies themselves. Regardless, we're confident all cluster operations will have time to migrate. If you have more questions about the dockershim removal, refer @@ -55,8 +57,8 @@ The results show that we still have a lot of ground to cover to help you to migrate smoothly. Other container runtimes exist, and have been promoted extensively. However, many users told us they still rely on dockershim, and sometimes have dependencies that need to be re-worked. Some of these -dependencies are outside of your control. Based on the feedback received from -you, here are some of the steps we are taking to help. +dependencies are outside of your control. Based on your feedback, here are some +of the steps we are taking to help. ## Our next steps @@ -72,13 +74,14 @@ Based on the feedback you provided: If you're part of a project with dependencies on dockershim, or if you're interested in helping with the migration effort, please join us! There's always room for more contributors, whether to our transition tools or to our -documentation. To get started, say hello in +documentation. To get started, say hello in the [#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G) -channel on [Kuberentes Slack](https://slack.kubernetes.io/)! +channel on [Kubernetes Slack](https://slack.kubernetes.io/)! ## Final thoughts -As a project, we've already seen cluster operators increasingly adopt of other container runtimes through 2021. +As a project, we've already seen cluster operators increasingly adopt other +container runtimes through 2021. We believe there are no major blockers to migration. The steps we're taking to improve the migration experience will light the path more clearly for you. @@ -89,7 +92,8 @@ hiccups or issues. The community has discussed at length whether postponing the dockershim removal would be helpful. For example, we recently talked about it in the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid) and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx). -We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it once last year because the adoption rate of other +We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it +once in 2021 because the adoption rate of other runtimes was lower than we wanted, which also gave us more time to identify potential blocking issues. From 36a5a39a3566af5556e31a589a2ac34c57eda197 Mon Sep 17 00:00:00 2001 From: Sascha Grunert Date: Mon, 10 Jan 2022 09:52:33 +0100 Subject: [PATCH 105/145] Update CRI description to be more verbose Signed-off-by: Sascha Grunert --- content/en/docs/concepts/architecture/cri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/cri.md b/content/en/docs/concepts/architecture/cri.md index e8391ca34b..02f6d8a199 100644 --- a/content/en/docs/concepts/architecture/cri.md +++ b/content/en/docs/concepts/architecture/cri.md @@ -15,7 +15,7 @@ each Node in your cluster, so that the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch {{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers. -{{< glossary_definition term_id="container-runtime-interface" length="all" >}} +{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="container-runtime-interface" length="all" >}} From a35da2ba7f508df547dd32c2ce4e16abbe4d3ffc Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Mon, 10 Jan 2022 17:57:32 +0800 Subject: [PATCH 106/145] Fix wrong capitalization for preemptionPolicy field --- .../scheduling-eviction/pod-priority-preemption.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md index fff925b6c5..63776520a9 100644 --- a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -106,7 +106,7 @@ description: "This priority class should be used for XYZ service pods only." {{< feature-state for_k8s_version="v1.19" state="beta" >}} -Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue +Pods with `preemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue, @@ -122,16 +122,16 @@ allowing other pods with lower priority to be scheduled before them. Non-preempting pods may still be preempted by other, high-priority pods. -`PreemptionPolicy` defaults to `PreemptLowerPriority`, +`preemptionPolicy` defaults to `PreemptLowerPriority`, which will allow pods of that PriorityClass to preempt lower-priority pods (as is existing default behavior). -If `PreemptionPolicy` is set to `Never`, +If `preemptionPolicy` is set to `Never`, pods in that PriorityClass will be non-preempting. An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. -The high priority job with `PreemptionPolicy: Never` will be scheduled +The high priority job with `preemptionPolicy: Never` will be scheduled ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free. From 1c8db8fde89af27b19c11144a990c6aeaaa7a12b Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Mon, 10 Jan 2022 18:29:09 +0800 Subject: [PATCH 107/145] [zh]Resync task-tutorial-prereqs.md --- content/zh/includes/task-tutorial-prereqs.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/zh/includes/task-tutorial-prereqs.md b/content/zh/includes/task-tutorial-prereqs.md index 822c01fe19..49d28ea552 100644 --- a/content/zh/includes/task-tutorial-prereqs.md +++ b/content/zh/includes/task-tutorial-prereqs.md @@ -1,11 +1,12 @@ 你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 -如果你还没有集群，你可以通过 [Minikube](/zh/docs/tasks/tools/#minikube) 构建一 -个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建： +建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 +如果你还没有集群，你可以通过 [Minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) +构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建： From 27d400d0e60c8dfa5f6e118ec822a39e2463e93e Mon Sep 17 00:00:00 2001 From: Jayesh Srivastava Date: Mon, 10 Jan 2022 22:00:54 +0530 Subject: [PATCH 108/145] Update localization.md --- content/en/docs/contribute/localization.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 592b59ded9..bd11ae6cb5 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -249,6 +249,7 @@ Home | [All heading and subheading URLs](/docs/home/) Setup | [All heading and subheading URLs](/docs/setup/) Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file +Releases | [All heading and subheading URLs](/releases) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: From 5030dec7113b96f21c10e67513a640f93ae68bcb Mon Sep 17 00:00:00 2001 From: zhangtaikun Date: Tue, 11 Jan 2022 09:31:09 +0800 Subject: [PATCH 109/145] Fix wrong capitalization for preemptionPolicy field in zh. --- .../pod-priority-preemption.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 7c9fe009c3..33cf14c540 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -177,7 +177,7 @@ description: "此优先级类应仅用于 XYZ 服务 Pod。" {{< feature-state for_k8s_version="v1.19" state="beta" >}} -Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue +Pods with `preemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue, @@ -197,7 +197,7 @@ high-priority pods. {{< feature-state for_k8s_version="v1.19" state="beta" >}} -配置了 `PreemptionPolicy: Never` 的 Pod 将被放置在调度队列中较低优先级 Pod 之前， +配置了 `preemptionPolicy: Never` 的 Pod 将被放置在调度队列中较低优先级 Pod 之前， 但它们不能抢占其他 Pod。等待调度的非抢占式 Pod 将留在调度队列中，直到有足够的可用资源， 它才可以被调度。非抢占式 Pod，像其他 Pod 一样，受调度程序回退的影响。 这意味着如果调度程序尝试这些 Pod 并且无法调度它们，它们将以更低的频率被重试， @@ -206,26 +206,26 @@ high-priority pods. 非抢占式 Pod 仍可能被其他高优先级 Pod 抢占。 -`PreemptionPolicy` 默认为 `PreemptLowerPriority`， +`preemptionPolicy` 默认为 `PreemptLowerPriority`， 这将允许该 PriorityClass 的 Pod 抢占较低优先级的 Pod（现有默认行为也是如此）。 -如果 `PreemptionPolicy` 设置为 `Never`，则该 PriorityClass 中的 Pod 将是非抢占式的。 +如果 `preemptionPolicy` 设置为 `Never`，则该 PriorityClass 中的 Pod 将是非抢占式的。 数据科学工作负载是一个示例用例。用户可以提交他们希望优先于其他工作负载的作业， 但不希望因为抢占运行中的 Pod 而导致现有工作被丢弃。 -设置为 `PreemptionPolicy: Never` 的高优先级作业将在其他排队的 Pod 之前被调度， +设置为 `preemptionPolicy: Never` 的高优先级作业将在其他排队的 Pod 之前被调度， 只要足够的集群资源“自然地”变得可用。 @@ -664,4 +664,4 @@ kubelet 使用优先级来确定 [默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) * 了解 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) * 了解 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) -* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) \ No newline at end of file +* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) From f6ae550af462500900467d2df2d4b244a83c540d Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Tue, 11 Jan 2022 10:26:58 +0530 Subject: [PATCH 110/145] Add glossary_tooltip for StatefulSet --- .../concepts/overview/working-with-objects/common-labels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index 3053544cd2..9dd68902da 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -42,7 +42,7 @@ on every resource object. | `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string | | `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string | -To illustrate these labels in action, consider the following StatefulSet object: +To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object: ```yaml apiVersion: apps/v1 From 5a5b4d8a70dcf595887b12d7b6d6403944f75662 Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Tue, 11 Jan 2022 10:33:07 +0530 Subject: [PATCH 111/145] Comment YAML to specify excerpt --- .../docs/concepts/overview/working-with-objects/common-labels.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index 9dd68902da..210d33dcd4 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -45,6 +45,7 @@ on every resource object. To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object: ```yaml +# This is an excerpt apiVersion: apps/v1 kind: StatefulSet metadata: From b930314a643ee0d8c1f7041bb8c3227f2513493c Mon Sep 17 00:00:00 2001 From: Vitthal Sai Date: Tue, 11 Jan 2022 14:24:09 +0530 Subject: [PATCH 112/145] Add glossary_tooltip for object --- content/en/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 0974089f8d..74e81092ae 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -33,7 +33,7 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP 1. The kubelet on a node self-registers to the control plane 2. You (or another human user) manually add a Node object -After you create a Node object, or the kubelet on a node self-registers, the +After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest: From 7e067efddc14041c5eb4e4a1bbd87c3fb40c4770 Mon Sep 17 00:00:00 2001 From: Rory McCune Date: Wed, 5 Jan 2022 11:18:04 +0000 Subject: [PATCH 113/145] Update content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md Blog Post from SIG-Security docs on securing admission controllers. Co-Authored-By: Tim Bannister Co-Authored-By: Rey Lejano Co-Authored-By: Nate W. <4453979+nate-double-u@users.noreply.github.com> --- ...22-01-19-Securing-Admission-Controllers.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md diff --git a/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md new file mode 100644 index 0000000000..002b2bd531 --- /dev/null +++ b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md @@ -0,0 +1,44 @@ +--- +layout: blog +title: "Securing Admission Controllers" +date: 2022-01-19 +slug: secure-your-admission-controllers-and-webhooks +--- + +**Author:** Rory McCune (Aqua Security) + +[Admission control](/docs/reference/access-authn-authz/admission-controllers/) is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of ways including restricting the privileges of workloads and ensuring that images deployed to the cluster meet organization’s security requirements. + +However, as with any additional component added to a cluster, security risks can present themselves. A security risk example is if the deployment and management of the admission controller are not handled correctly. To help admission controller users and designers manage these risks appropriately, the [security documentation](https://github.com/kubernetes/community/tree/master/sig-security#security-docs) subgroup of SIG Security has spent some time developing a [threat model for admission controllers](https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control). This threat model looks at likely risks which may arise from the incorrect use of admission controllers, which could allow security policies to be bypassed, or even allow an attacker to get unauthorised access to the cluster. + +From the threat model, we developed a set of security best practices that should be adopted to ensure that cluster operators can get the security benefits of admission controllers whilst avoiding any risks from using them. + +## Admission controllers and good practices for security + +From the threat model, a couple of themes emerged around how to ensure the security of admission controllers. + +### Secure webhook configuration + +It’s important to ensure that any security component in a cluster is well configured and admission controllers are no different here. There are a couple of security best practices to consider when using admission controllers + +* **Correctly configured TLS for all webhook traffic**. Communications between the API server and the admission controller webhook should be authenticated and encrypted to ensure that attackers who may be in a network position to view or modify this traffic cannot do so. To achieve this access the API server and webhook must be using certificates from a trusted certificate authority so that they can validate their mutual identities +* **Only authenticated access allowed**. If an attacker can send an admission controller large numbers of requests, they may be able to overwhelm the service causing it to fail. Ensuring all access requires strong authentication should mitigate that risk. +* **Admission controller fails closed**. This is a security practice that has a tradeoff, so whether a cluster operator wants to configure it will depend on the cluster’s threat model. If an admission controller fails closed, when the API server can’t get a response from it, all deployments will fail. This stops attackers bypassing the admission controller by disabling it, but, can disrupt the cluster’s operation. As clusters can have multiple webhooks, one approach to hit a middle ground might be to have critical controls on a fail closed setups and less critical controls allowed to fail open. +* **Regular reviews of webhook configuration**. Configuration mistakes can lead to security issues, so it’s important that the admission controller webhook configuration is checked to make sure the settings are correct. This kind of review could be done automatically by an Infrastructure As Code scanner or manually by an administrator. + + +### Secure cluster configuration for admission control + +In most cases, the admission controller webhook used by a cluster will be installed as a workload in the cluster. As a result, it’s important to ensure that Kubernetes' security features that could impact its operation are well configured. + +* **Restrict [RBAC](/docs/reference/access-authn-authz/rbac/) rights**. Any user who has rights which would allow them to modify the configuration of the webhook objects or the workload that the admission controller uses could disrupt its operation. So it’s important to make sure that only cluster administrators have those rights. +* **Prevent privileged workloads**. One of the realities of container systems is that if a workload is given certain privileges, it will be possible to break out to the underlying cluster node and impact other containers on that node. Where admission controller services run in the cluster they’re protecting, it’s important to ensure that any requirement for privileged workloads is carefully reviewed and restricted as much as possible. +* **Strictly control external system access**. As a security service in a cluster admission controller systems will have access to sensitive information like credentials. To reduce the risk of this information being sent outside the cluster, [network policies](/docs/concepts/services-networking/network-policies/) should be used to restrict the admission controller services access to external networks. +* **Each cluster has a dedicated webhook**. Whilst it may be possible to have admission controller webhooks that serve multiple clusters, there is a risk when using that model that an attack on the webhook service would have a larger impact where it’s shared. Also where multiple clusters use an admission controller there will be increased complexity and access requirements, making it harder to secure. + + +### Admission controller rules + +A key element of any admission controller used for Kubernetes security is the rulebase it uses. The rules need to be able to accurately meet their goals avoiding false positive and false negative results. + +* **Regularly test and review rules**. Admission controller rules need to be tested to ensure their accuracy. They also need to be regularly reviewed as the Kubernetes API will change with each new version, and rules need to be assessed with each Kubernetes release to understand any changes that may be required to keep them up to date. From c073285fb37eeb9c3f6c5f7e10f3c2b0f10419b7 Mon Sep 17 00:00:00 2001 From: ixodie Date: Tue, 11 Jan 2022 10:53:58 -0500 Subject: [PATCH 114/145] Removing Romana Romana is defunct and has been removed from main networking docs already. --- content/en/docs/concepts/cluster-administration/networking.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 074bcff31e..ca026b204f 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -79,7 +79,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. From d9f59663405ef88ba96e6011ab097c922aaa6291 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:26:26 +0900 Subject: [PATCH 115/145] Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md Co-authored-by: atoato88 --- .../migrating-from-dockershim/find-out-runtime-you-use.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md index 63ef19d50a..a6d297bdd8 100644 --- a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -7,6 +7,7 @@ weight: 10 このページでは、クラスター内のノードが使用している[コンテナランタイム](/docs/setup/production-environment/container-runtimes/)を確認する手順を概説しています。 + クラスターの実行方法によっては、ノード用のコンテナランタイムが事前に設定されている場合と、設定する必要がある場合があります。 マネージドKubernetesサービスを使用している場合、ノードに設定されているコンテナランタイムを確認するためのベンダー固有の方法があるかもしれません。 このページで説明する方法は、`kubectl`の実行が許可されていればいつでも動作するはずです。 From af6e6eb46ee704abb454d01e5c39c94b2de68e2c Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:27:37 +0900 Subject: [PATCH 116/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 58cc6d47a7..2615e8134a 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -67,7 +67,7 @@ etcd-ca Dec 28, 2029 23:36 UTC 9y no front-proxy-ca Dec 28, 2029 23:36 UTC 9y no ``` -このコマンドは、`/etc/kubernetes/pki`フォルダ内のクライアント証明書と、kubeadmが使用するKUBECONFIGファイル(`admin.conf`,`controller-manager.conf`,`scheduler.conf`に埋め込まれたクライアント証明書の有効期限/残余時間を表示します)。 +このコマンドは、`/etc/kubernetes/pki`フォルダ内のクライアント証明書と、kubeadmが使用するKUBECONFIGファイル(`admin.conf`,`controller-manager.conf`,`scheduler.conf`)に埋め込まれたクライアント証明書の有効期限/残余時間を表示します。 また、証明書が外部管理されている場合、kubeadmはユーザーに通知します。この場合、ユーザーは証明書の更新を手動または他のツールを使用して管理する必要があります。 From 0228a1af9afab2f850b3427e978b03789e20e7a5 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:07 +0900 Subject: [PATCH 117/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 2615e8134a..4a0486e050 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -76,7 +76,7 @@ front-proxy-ca Dec 28, 2029 23:36 UTC 9y no {{< /warning >}} {{< note >}} -kubeadmは`/var/lib/kubelet/pki`以下にあるローテート可能な証明書で[証明書の自動更新](/docs/task/tls/certificate-rotation/)のためkubeletを構成するので`kubelet.conf`は上記のリストに含まれません。 +kubeadmは`/var/lib/kubelet/pki`以下にあるローテート可能な証明書でkubeletの[証明書の自動更新](/docs/task/tls/certificate-rotation/)を構成するので`kubelet.conf`は上記のリストに含まれません。 期限切れのkubeletクライアント証明書を修復するには、[Kubelet クライアント証明書のローテーションに失敗しました](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert)を参照ください。 {{< /note >}} From 9588612861527b0586994894967db3bc528b0bc2 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:15 +0900 Subject: [PATCH 118/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 4a0486e050..de696db851 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -113,6 +113,7 @@ kubeadmバージョン1.17より前のバージョンでは、`kubeadm upgrade n ## 手動による証明書更新 `kubeadm certs renew` コマンドを使えば、いつでも証明書を手動で更新することができます。 + このコマンドは`/etc/kubernetes/pki`に格納されているCA(またはfront-proxy-CA)の証明書と鍵を使って更新を行います。 コマンド実行後、コントロールプレーンのPodを再起動する必要があります。 From 2f5b1eb9cc45edccf7f03916e9ad27ab679ca605 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:21 +0900 Subject: [PATCH 119/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index de696db851..eec3c80539 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -155,6 +155,7 @@ Kubernetesの認証局は、そのままでは機能しません。 [cert-manager](https://cert-manager.io/docs/configuration/ca/)などの外部署名者を設定するか、組み込みの署名者を使用することができます。 ビルトインサイナーは[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)に含まれるものです。 + ビルトインサイナーを有効にするには、`--cluster-signing-cert-file`と`--cluster-signing-key-file`フラグを渡す必要があります。 新しいクラスタを作成する場合は、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)を使用します。 From dbb4ada8b4c28cfe3f192c616d7d5282f2e33291 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:26 +0900 Subject: [PATCH 120/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index eec3c80539..4d96fa5142 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -187,7 +187,7 @@ kubeadmの用語では、通常ディスク上のCAによって署名される CSRとそれに付随する秘密鍵の両方が出力されます。 ディレクトリを`--csr-dir`で渡すと、指定した場所にCSRを出力することができます。 -csr-dir`を指定しない場合は、デフォルトの証明書ディレクトリ(`/etc/kubernetes/pki`)が使用されます。 +`csr-dir`を指定しない場合は、デフォルトの証明書ディレクトリ(`/etc/kubernetes/pki`)が使用されます。 証明書は`kubeadm certs renew --csr-only`で更新することができます。 `kubeadm init`と同様に、`--csr-dir`フラグで出力先ディレクトリを指定することができます。 From 0b3585e449f8e2fc6e276ecbb17920bd070ef5d6 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:38 +0900 Subject: [PATCH 121/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 4d96fa5142..c5260ffbb1 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -195,7 +195,7 @@ CSRとそれに付随する秘密鍵の両方が出力されます。 CSRには、証明書の名前、ドメイン、IPが含まれますが、用途は指定されません。 証明書を発行する際に、[正しい証明書の使用法](/docs/setup/best-practices/certificates/#all-certificates)を指定するのはCAの責任です。 -* `opensl`では、[`openssl ca`コマンド](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)を使って行います。 +* `openssl`では、[`openssl ca`コマンド](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)を使って行います。 * `cfssl`では、[configファイルのusages](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)で指定します。 From 7e23cb0bdaf8255f3243589c6cc8a3ecff6750d5 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:28:47 +0900 Subject: [PATCH 122/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index c5260ffbb1..06b639273f 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -259,7 +259,7 @@ Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に 詳しくは[Certificate Rotation] (/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)をご覧ください。 これらのCSRを自動的に承認するためのソリューションをお探しの場合は、以下をお勧めします。 -クラウドプロバイダーに連絡し、CSRの署名者がいるかどうか尋ねてください。 +クラウドプロバイダーに連絡し、ノードの識別をアウトオブバンドのメカニズムで行うCSRの署名者がいるかどうか尋ねてください。 ノードの識別をアウトオブバンドのメカニズムで行います。 {{% thirdparty-content %}} From b1021a627c0c86efbe13ff2308597c3203c446a8 Mon Sep 17 00:00:00 2001 From: Wang Date: Wed, 12 Jan 2022 14:29:03 +0900 Subject: [PATCH 123/145] Update content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md Co-authored-by: atoato88 --- .../ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 06b639273f..9ab39e80c4 100644 --- a/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -260,7 +260,6 @@ Kubeadmは`KubeletConfiguration`フィールド`rotateCertificates`を`true`に これらのCSRを自動的に承認するためのソリューションをお探しの場合は、以下をお勧めします。 クラウドプロバイダーに連絡し、ノードの識別をアウトオブバンドのメカニズムで行うCSRの署名者がいるかどうか尋ねてください。 -ノードの識別をアウトオブバンドのメカニズムで行います。 {{% thirdparty-content %}} From b49701b5664448efa4d06a531990baa13a3db78a Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Wed, 12 Jan 2022 12:02:18 +0200 Subject: [PATCH 124/145] Fix link to OWNERS_ALIASES --- .../docs/contribute/participate/roles-and-responsibilities.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md index e59ffe4fe3..c577c3f8be 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -147,7 +147,7 @@ separately for reviewer status in SIG Docs. To apply: 1. Open a pull request that adds your GitHub user name to a section of the - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) file + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file in the `kubernetes/website` repository. {{< note >}} @@ -219,7 +219,7 @@ separately for approver status in SIG Docs. To apply: 1. Open a pull request adding yourself to a section of the - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file in the `kubernetes/website` repository. {{< note >}} From 3200993466dc2ba0c7f73c9b75980c8a01ee8b8f Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Wed, 12 Jan 2022 12:03:09 +0200 Subject: [PATCH 125/145] [ko] Fix link to OWNERS_ALIASES --- .../docs/contribute/participate/roles-and-responsibilities.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 5f4e1605dd..8306f824e9 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -144,7 +144,7 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 지원하려면, 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) 파일의 섹션에 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 파일의 섹션에 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. {{< note >}} @@ -216,7 +216,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 지원하려면 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. {{< note >}} From 35d0ddd312b10b5ae161a42cb2fdf5ec8bf47987 Mon Sep 17 00:00:00 2001 From: Shivam Singhal Date: Wed, 12 Jan 2022 12:04:03 +0200 Subject: [PATCH 126/145] [zh] Fix link to OWNERS_ALIASES --- .../contribute/participate/roles-and-responsibilities.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/contribute/participate/roles-and-responsibilities.md b/content/zh/docs/contribute/participate/roles-and-responsibilities.md index 2b91550a60..7739af7584 100644 --- a/content/zh/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/zh/docs/contribute/participate/roles-and-responsibilities.md @@ -269,7 +269,7 @@ To apply: 1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 文件的特定节。 {{< note >}} @@ -383,7 +383,7 @@ When you meet the [requirements](https://github.com/kubernetes/community/blob/ma From 04b4356744e952a71a436fc50817f2b1182567fe Mon Sep 17 00:00:00 2001 From: Josh Berkus Date: Thu, 13 Jan 2022 17:43:28 -0800 Subject: [PATCH 140/145] Fix link to dev@kubernetes group. Signed-off-by: Josh Berkus --- content/fr/docs/setup/learning-environment/minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 2ab0b3ae5a..94bd0744f5 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -527,5 +527,5 @@ Pour plus d'informations sur Minikube, voir la [proposition](https://git.k8s.io/ Les contributions, questions et commentaires sont les bienvenus et sont encouragés ! Les développeurs de minikube sont dans le canal #minikube du [Slack](https://kubernetes.slack.com) de Kubernetes (recevoir une invitation [ici](http://slack.kubernetes.io/)). -Nous avons également la liste de diffusion [kubernetes-dev Google Groupes](https://groups.google.com/forum/#!forum/kubernetes-dev). +Nous avons également la liste de diffusion [dev@kubernetes Google Groupes](https://groups.google.com/a/kubernetes.io/g/dev/). Si vous publiez sur la liste, veuillez préfixer votre sujet avec "minikube:". From e346ea41ee6198c07c5f24c048b79231e3eb579a Mon Sep 17 00:00:00 2001 From: Alex Zielenski Date: Thu, 13 Jan 2022 18:51:01 -0800 Subject: [PATCH 141/145] Fix typo for OpenAPIV3 and OpenAPIEnums If a user were to copy & paste from the docs into the feature-gate option they would receive the error `flag: unrecognized feature gate: OpenAPIv3` or `flag: unrecognized feature gate: OpenAPIEnum`. This change uses the correct case for `V` and uses the plural form for `Enums` as the command line parser expects. --- .../command-line-tools-reference/feature-gates.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 84697c03ae..f9d2336f07 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -167,8 +167,8 @@ different Kubernetes components. | `NodeSwap` | `false` | Alpha | 1.22 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | Beta | 1.19 | | -| `OpenAPIEnum` | `false` | Alpha | 1.23 | | -| `OpenAPIv3` | `false` | Alpha | 1.23 | | +| `OpenAPIEnums` | `false` | Alpha | 1.23 | | +| `OpenAPIV3` | `false` | Alpha | 1.23 | | | `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | | | `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | 1.21 | | `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | | @@ -914,9 +914,9 @@ Each feature gate is designed for enabling/disabling a specific feature: Must be used with `KubeletConfiguration.failSwapOn` set to false. For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory) - `NonPreemptingPriority`: Enable `preemptionPolicy` field for PriorityClass and Pod. -- `OpenAPIEnum`: Enables populating "enum" fields of OpenAPI schemas in the +- `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the spec returned from the API server. -- `OpenAPIv3`: Enables the API server to publish OpenAPI v3. +- `OpenAPIV3`: Enables the API server to publish OpenAPI v3. - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from being deleted when it is still used by any Pod. - `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) From 80e2f669a0cdb1d5d365d35e9d75c953e5bd020d Mon Sep 17 00:00:00 2001 From: GuyTempleton Date: Fri, 14 Jan 2022 10:30:44 +0000 Subject: [PATCH 142/145] Docs - EN - Concepts - Correct Pod-Conditions Anchor Link --- content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 9656a816e7..07cf3c77a6 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -229,7 +229,7 @@ when both the following statements apply: * All conditions specified in `readinessGates` are `True`. When a Pod's containers are Ready but at least one custom condition is missing or -`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`. +`False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`. ## Container probes From 0e98775ec78ced935dcb0d8a11ee8cb052d37ccb Mon Sep 17 00:00:00 2001 From: Ihor Sychevskyi Date: Sat, 15 Jan 2022 10:49:06 +0300 Subject: [PATCH 143/145] [uk] update date to mention KubeCon NA 2022 --- content/uk/_index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/uk/_index.html b/content/uk/_index.html index ebf3f6ea18..29f6941477 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -62,12 +62,12 @@ Kubernetes - проект з відкритим вихідним кодом. В

- Відвідайте KubeCon у Північній Америці, 11-15 жовтня 2021 року -
-
-
-
Відвідайте KubeCon в Європі, 17-20 травня 2022 року +
+
+
+
+ Відвідайте KubeCon у Північній Америці, 24-28 жовтня 2022 року
From 60551bc338c07c14af38254da7c1db264198ebf1 Mon Sep 17 00:00:00 2001 From: Meysam Azad Date: Sat, 15 Jan 2022 13:26:50 +0300 Subject: [PATCH 144/145] =?UTF-8?q?typo:=20remove=20redundant=20prepositio?= =?UTF-8?q?n=20=E2=9C=8F=EF=B8=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/en/docs/concepts/workloads/controllers/job.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index d2284d9dbb..8ff46d4f50 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -615,7 +615,7 @@ spec: ``` The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting -`manualSelector: true` tells the system to that you know what you are doing and to allow this +`manualSelector: true` tells the system that you know what you are doing and to allow this mismatch. ### Job tracking with finalizers From b4f8f26ec02657e0545c1800cd66bffc80ac3b0d Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Fri, 14 Jan 2022 18:12:38 +0800 Subject: [PATCH 145/145] [zh]Resync cluster-administration networking file --- .../cluster-administration/networking.md | 276 +----------------- 1 file changed, 13 insertions(+), 263 deletions(-) diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index 2a44b99e44..e7c0ab9321 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -40,6 +40,8 @@ application has to take ports as flags, the API servers have to know how to insert dynamic port numbers into configuration blocks, services have to know how to find each other, etc. Rather than deal with this, Kubernetes takes a different approach. + +To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/). --> Kubernetes 的宗旨就是在应用之间共享机器。 通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间 @@ -49,80 +51,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 - -## Kubernetes 网络模型 {#the-kubernetes-network-model} - -每一个 `Pod` 都有它自己的IP地址，这就意味着你不需要显式地在每个 `Pod` 之间创建链接， -你几乎不需要处理容器端口到主机端口之间的映射。 -这将创建一个干净的、向后兼容的模型，在这个模型里，从端口分配、命名、服务发现、 -负载均衡、应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。 - -Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）： - -* 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 -* 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有Pod通信 - -备注：仅针对那些支持 `Pods` 在主机网络中运行的平台（比如：Linux）： - -* 那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信 - - -这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容， -如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ， -这样就可以和其他的虚拟机进行通信，这是基本相同的模型。 - -Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。 -这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达各个端口。 -这也意味着 `Pod` 内的容器都需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同， -这也被称为“一个 Pod 一个 IP”模型。 - - -如何实现这一点是正在使用的容器运行时的特定信息。 - -也可以在 `node` 本身通过端口去请求你的 `Pod`（称之为主机端口）， -但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 -`Pod` 自己并不知道这些主机端口是否存在。 - +要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。 -### Apstra 的 AOS - -[AOS](https://www.apstra.com/products/aos/) 是一个基于意图的网络系统， -可以通过一个简单的集成平台创建和管理复杂的数据中心环境。 -AOS 利用高度可扩展的分布式设计来消除网络中断，同时将成本降至最低。 - -AOS 参考设计当前支持三层连接的主机，这些主机消除了旧的两层连接的交换问题。 -这些三层连接的主机可以是 Linux（Debian、Ubuntu、CentOS）系统， -它们直接在机架式交换机（TOR）的顶部创建 BGP 邻居关系。 -AOS 自动执行路由邻接，然后提供对 Kubernetes 部署中常见的路由运行状况注入（RHI）的精细控制。 - -AOS 具有一组丰富的 REST API 端点，这些端点使 Kubernetes 能够根据应用程序需求快速更改网络策略。 -进一步的增强功能将用于网络设计的 AOS Graph 模型与工作负载供应集成在一起， -从而为私有云和公共云提供端到端管理系统。 - -AOS 支持使用包括 Cisco、Arista、Dell、Mellanox、HPE 在内的制造商提供的通用供应商设备， -以及大量白盒系统和开放网络操作系统，例如 Microsoft SONiC、Dell OPX 和 Cumulus Linux。 - -想要更详细地了解 AOS 系统是如何工作的可以点击这里：https://www.apstra.com/products/how-it-works/ - -### Big Switch Networks 的 Big Cloud Fabric - -[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) 是一个基于云原生的网络架构， -旨在在私有云或者本地环境中运行 Kubernetes。 -它使用统一的物理和虚拟 SDN，Big Cloud Fabric 解决了固有的容器网络问题， -比如负载均衡、可见性、故障排除、安全策略和容器流量监控。 - -在 Big Cloud Fabric 的虚拟 Pod 多租户架构的帮助下，容器编排系统 -（比如 Kubernetes、RedHat OpenShift、Mesosphere DC/OS 和 Docker Swarm） -将与 VM 本地编排系统（比如 VMware、OpenStack 和 Nutanix）进行本地集成。 -客户将能够安全地互联任意数量的这些集群，并且在需要时启用他们之间的租户间通信。 - -在最新的 [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html) 上， -BCF 被 Gartner 认为是非常有远见的。 -而 BCF 的一条关于 Kubernetes 的本地部署（其中包括 Kubernetes、DC/OS 和在不同地理区域的多个 -DC 上运行的 VMware）也在[这里](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)被引用。 - @@ -313,7 +183,6 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu [CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如 [Flannel](https://github.com/coreos/flannel#flannel)、 [Calico](https://docs.projectcalico.org/)、 -[Romana](https://romana.io)、 [Weave-net](https://www.weave.works/products/weave-net/)。 CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multi-ip-addresses-per-pod)， @@ -362,18 +231,6 @@ Coil operates with a low overhead compared to bare metal, and allows you to defi [Coil](https://github.com/cybozu-go/coil) 是一个为易于集成、提供灵活的出站流量网络而设计的 CNI 插件。 与裸机相比，Coil 的额外操作开销低，并允许针对外部网络的出站流量任意定义 NAT 网关。 - -### Contiv - -[Contiv](https://github.com/contiv/netplugin) -为各种使用情况提供了一个可配置网络（使用了 BGP 的本地 L3， -使用 vxlan 、经典 L2 或 Cisco-SDN/ACI 的覆盖网络）。 -[Contiv](https://contiv.io) 是完全开源的。 - -### Google Compute Engine (GCE) +### Hybridnet -对于 Google Compute Engine 的集群配置脚本， -[高级路由器](https://cloud.google.com/vpc/docs/routes) 用于为每个虚机分配一个子网（默认是 `/24` - 254个 IP）， -绑定到该子网的任何流量都将通过 GCE 网络结构直接路由到虚机。 -这是除了分配给虚机的“主” IP 地址之外的一个补充，该 IP 地址经过 NAT 转换以用于访问外网。 -Linux 网桥（称为“cbr0”）被配置为存在于该子网中，并被传递到 Docker 的 --bridge 参数上。 - -Docker 会以这样的参数启动： - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -这个网桥是由 Kubelet（由 `--network-plugin=kubenet` 参数控制）根据节点的 `.spec.podCIDR` 参数创建的。 - -Docker 将会从 `cbr-cidr` 块分配 IP。 -容器之间可以通过 `cbr0` 网桥相互访问，也可以访问节点。 -这些 IP 都可以在 GCE 的网络中被路由。 -而 GCE 本身并不知道这些 IP，所以不会对访问外网的流量进行 NAT。 -为了实现此目的，使用了 `iptables` 规则来伪装（又称为 SNAT，使数据包看起来好像是来自“节点”本身）， -将通信绑定到 GCE 项目网络（10.0.0.0/8）之外的 IP。 - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -最后，在内核中启用了 IP 转发（因此内核将处理桥接容器的数据包）： - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -所有这些的结果是所有 Pod 都可以互相访问，并且可以将流量发送到互联网。 +[Hybridnet](https://github.com/alibaba/hybridnet) 是一个为混合云设计的开源 CNI 插件， +它为一个或多个集群中的容器提供覆盖和底层网络。 Overlay 和 underlay 容器可以在同一个节点上运行， +并具有集群范围的双向网络连接。 ### Multus (a Multi Network plugin) @@ -591,7 +380,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p 使用 Kubernetes 中基于 CRD 的网络对象来支持实现 Kubernetes 多网络系统。 Multus 支持所有[参考插件](https://github.com/containernetworking/plugins)（比如： -[Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)、 +[Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md)、 [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp)、 [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan) ） 来实现 CNI 规范和第三方插件（比如： @@ -623,28 +412,6 @@ NSX-T 可以为多云及多系统管理程序环境提供网络虚拟化，并 以及 NSX-T 与基于容器的 CaaS/PaaS 平台（例如 Pivotal Container Service（PKS）和 OpenShift）之间的集成。 -### Nuage Networks VCS (Virtualized Cloud Services) - -[Nuage](https://www.nuagenetworks.net) 提供了一个高度可扩展的基于策略的软件定义网络（SDN）平台。 -Nuage 使用开源的 Open vSwitch 作为数据平面，以及基于开放标准构建具有丰富功能的 SDN 控制器。 - -Nuage 平台使用覆盖层在 Kubernetes Pod 和非 Kubernetes 环境（VM 和裸机服务器）之间提供基于策略的无缝联网。 -Nuage 的策略抽象模型在设计时就考虑到了应用程序，并且可以轻松声明应用程序的细粒度策略。 -该平台的实时分析引擎可为 Kubernetes 应用程序提供可见性和安全性监控。 - - -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/) 是一个较为成熟的解决方案，但同时也增加了构建覆盖网络的复杂性。 -这也得到了几个网络系统的“大商店”的拥护。 - ### OVN (开放式虚拟网络) OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。 它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。 该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。 - -### Romana - -[Romana](https://romana.io) 是一个开源网络和安全自动化解决方案。 -它可以让你在没有覆盖网络的情况下部署 Kubernetes。 -Romana 支持 Kubernetes [网络策略](/zh/docs/concepts/services-networking/network-policies/)， -来提供跨网络命名空间的隔离。 -