From abd888438033adc95056b11228bba6c26d4666ba Mon Sep 17 00:00:00 2001 From: Ana Carolina Rodrigues Date: Mon, 30 Jan 2023 14:48:27 -0300 Subject: [PATCH 001/215] Add content/pt-br/docs/reference/issues-security/issues.md --- .../docs/reference/issues-security/issues.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 content/pt-br/docs/reference/issues-security/issues.md diff --git a/content/pt-br/docs/reference/issues-security/issues.md b/content/pt-br/docs/reference/issues-security/issues.md new file mode 100644 index 0000000000000..319ca3a586c8e --- /dev/null +++ b/content/pt-br/docs/reference/issues-security/issues.md @@ -0,0 +1,16 @@ +--- +title: Rastreador de Issue Kubernetes +weight: 10 +aliases: [/cve/,/cves/] +--- + +Para reportar um problema de segurança, siga [processo de divulgação de issues do Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability). + +O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando [ GitHub Issues ](https://github.com/kubernetes/kubernetes/issues/). + +* Oficial [lista de CVEs conhecidos](/docs/reference/issues-security/official-cve-feed/) + (vulnerabilidades de segurança) que foram anunciados pelo + [comitê de resposta de segurança](https://github.com/kubernetes/committee-security-response) +* [Problemas do gitHub relacionados ao CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) + +Anúncios relacionados à segurança são enviados para a lista de discussão [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce). \ No newline at end of file From b15ead71f5423e27cc76793f5392dbae24e976ca Mon Sep 17 00:00:00 2001 From: Wesley Hartford Date: Wed, 1 Feb 2023 07:55:10 -0800 Subject: [PATCH 002/215] Fix reference to file name in generated configMap Documentation prose refers to the file named `.properties`, the correct file name is `application.properties`. --- .../en/docs/tasks/manage-kubernetes-objects/kustomization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index 525c404ef744e..f53eae1d88296 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -120,7 +120,7 @@ metadata: ``` {{< note >}} -Each variable in the `.env` file becomes a separate key in the ConfigMap that you generate. This is different from the previous example which embeds a file named `.properties` (and all its entries) as the value for a single key. +Each variable in the `.env` file becomes a separate key in the ConfigMap that you generate. This is different from the previous example which embeds a file named `application.properties` (and all its entries) as the value for a single key. {{< /note >}} ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair: From f55090070743d9cea3cc8c33b1493ff476af40e0 Mon Sep 17 00:00:00 2001 From: Aayush Sharma Date: Thu, 2 Feb 2023 19:02:12 +0530 Subject: [PATCH 003/215] Kubecon 2023 dates updated --- content/hi/_index.html | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/hi/_index.html b/content/hi/_index.html index 640f3f104b74e..77bdcabb4798f 100644 --- a/content/hi/_index.html +++ b/content/hi/_index.html @@ -43,12 +43,11 @@

150+ माइक्रोसर्विसेज को कुबेरन

- अक्टूबर 11-15, 2021 को KubeCon North America में भाग लें + अप्रैल 18-21, 2023 KubeCon + CloudNativeCon Europe में भाग लें


-
- मई 17-20, 2022 को KubeCon Europe में भाग लें + 6-9 नवंबर, 2023 को KubeCon + CloudNativeCon North America में भाग लें
From 33c430b09313ee387ec70f98f700d7a4d2b02386 Mon Sep 17 00:00:00 2001 From: Aayush Sharma Date: Thu, 2 Feb 2023 19:03:27 +0530 Subject: [PATCH 004/215] Kubecon 2023 dates updated --- content/hi/_index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/content/hi/_index.html b/content/hi/_index.html index 77bdcabb4798f..2009559be3bab 100644 --- a/content/hi/_index.html +++ b/content/hi/_index.html @@ -47,6 +47,7 @@

150+ माइक्रोसर्विसेज को कुबेरन


+
6-9 नवंबर, 2023 को KubeCon + CloudNativeCon North America में भाग लें

From 9daccce6a9a00335d5b0dc90eb2ff1b5b900d1b6 Mon Sep 17 00:00:00 2001 From: Ana Carolina Rodrigues Date: Thu, 2 Feb 2023 18:10:30 -0300 Subject: [PATCH 005/215] Update content/pt-br/docs/reference/issues-security/issues.md --- content/pt-br/docs/reference/issues-security/issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/reference/issues-security/issues.md b/content/pt-br/docs/reference/issues-security/issues.md index 319ca3a586c8e..706a69f5fd0c8 100644 --- a/content/pt-br/docs/reference/issues-security/issues.md +++ b/content/pt-br/docs/reference/issues-security/issues.md @@ -1,7 +1,7 @@ --- title: Rastreador de Issue Kubernetes weight: 10 -aliases: [/cve/,/cves/] +aliases: [/pt-br/cve/,/pt-br/cves/] --- Para reportar um problema de segurança, siga [processo de divulgação de issues do Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability). From 96b174da80f59912b64690a0a6c6e5dd4e716c75 Mon Sep 17 00:00:00 2001 From: Yuiko Mouri Date: Mon, 6 Feb 2023 09:16:37 +0900 Subject: [PATCH 006/215] [ja]Fix invalid Japanese words --- content/ja/case-studies/sos/index.html | 2 +- .../concepts/configuration/manage-resources-containers.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/case-studies/sos/index.html b/content/ja/case-studies/sos/index.html index c63fa4ab516e6..07ab28aad6dcc 100644 --- a/content/ja/case-studies/sos/index.html +++ b/content/ja/case-studies/sos/index.html @@ -37,7 +37,7 @@

影響

SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。 {{< /case-studies/lead >}} -

SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。

+

SOSのオペレーターは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。

ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」

diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 499e2a7214976..8dc1b36f636b6 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -378,7 +378,7 @@ Kubernetesが使用しないようにする必要があります。 ## 拡張リソース {#extended-resources} 拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。 -これにより、クラスタオペレータはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。 +これにより、クラスタオペレーターはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。 拡張リソースを使用するためには、2つのステップが必要です。 第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。 @@ -394,7 +394,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。 各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。 ##### その他のリソース {#other-resources} -新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレータはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。 +新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。 この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。 `status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。 スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。 From e14d2871c3369d326532926509a96a95214c8e4e Mon Sep 17 00:00:00 2001 From: Toshiaki Inukai Date: Thu, 16 Feb 2023 02:05:09 +0000 Subject: [PATCH 007/215] [ja] Set heading IDs in daemonset.md and assign-pods-nodes.md --- .../workloads/controllers/daemonset.md | 32 +++++++++---------- .../assign-pods-nodes.md | 8 ++--- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 42647228e6180..32e62fb74b6c9 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -22,9 +22,9 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 -## DaemonSet Specの記述 +## DaemonSet Specの記述 {#writing-a-daemonset-spec} -### DaemonSetの作成 +### DaemonSetの作成 {#create-a-daemonset} ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 @@ -36,7 +36,7 @@ YAMLファイルに基づいてDaemonSetを作成します。 kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` -### 必須のフィールド +### 必須のフィールド {#required-fields} 他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 @@ -45,7 +45,7 @@ DaemonSetオブジェクトの名前は、有効な また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。 -### Podテンプレート +### Podテンプレート {#pod-template} `.spec.template`は`.spec`内での必須のフィールドの1つです。 @@ -55,7 +55,7 @@ Podに対する必須のフィールドに加えて、DaemonSet内のPodテン DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 -### Podセレクター +### Podセレクター {#pod-selector} `.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 @@ -70,14 +70,14 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。 -### 選択したNode上でPodを稼働させる +### 選択したNode上でPodを稼働させる {#running-pods-on-select-nodes} もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。 もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。 -## Daemon Podがどのようにスケジューリングされるか +## Daemon Podがどのようにスケジューリングされるか {#how-daemon-pods-are-scheduled} -### デフォルトスケジューラーによってスケジューリングされる場合 +### デフォルトスケジューラーによってスケジューリングされる場合 {#scheduled-by-default-scheduler} {{< feature-state for_k8s_version="1.17" state="stable" >}} @@ -102,7 +102,7 @@ nodeAffinity: さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。 -### TaintsとTolerations +### TaintsとTolerations {#taints-and-tolerations} DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 @@ -115,7 +115,7 @@ DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/t | `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 | -## Daemon Podとのコミュニケーション +## Daemon Podとのコミュニケーション {#communicating-with-daemon-pods} DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。: @@ -124,7 +124,7 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ - **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。 - **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。 -## DaemonSetの更新 +## DaemonSetの更新 {#updating-a-daemonset} もしNodeラベルが変更されたとき、そのDaemonSetは直ちに新しくマッチしたNodeにPodを追加し、マッチしなくなったNodeからPodを削除します。 @@ -134,9 +134,9 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。 -## DaemonSetの代替案 +## DaemonSetの代替案 {#alternatives-to-daemonset} -### Initスクリプト +### Initスクリプト {#init-scripts} Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`を使用する)、デーモンプロセスを稼働することが可能です。この方法は非常に良いですが、このようなプロセスをDaemonSetを介して起動することはいくつかの利点があります。 @@ -144,15 +144,15 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd` - デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。 - リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です(Dockerを介して直接起動する)。 -### ベアPod +### ベアPod {#bare-pods} 特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。 -### 静的Pod Pods +### 静的Pod Pods {#static-pods} Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 -### Deployment +### Deployment {#deployments} DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。 diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md index e2e4e1d647ca4..4e09dbaf9325a 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -7,13 +7,13 @@ weight: 120 このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。 -## {{% heading "prerequisites" %}} +## {{% heading "prerequisites" %}} {#before-you-begin} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -## ラベルをノードに追加する +## ラベルをノードに追加する {#add-a-label-to-a-node} 1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。 @@ -54,7 +54,7 @@ weight: 120 上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。 -## 選択したノードにスケジューリングされるPodを作成する +## 選択したノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-your-chosen-node} 以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。 @@ -79,7 +79,7 @@ weight: 120 nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` -## 特定のノードにスケジューリングされるPodを作成する +## 特定のノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-specific-node} `nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。 From 260d241ddc0d3e6b347cbeb74eddcb62060e5bf6 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Wed, 11 May 2022 11:28:31 +0300 Subject: [PATCH 008/215] [ru] Add RU localization for docs/concepts/containers/* Apply suggestions from code review Co-authored-by: Dmitry Shurupov --- content/ru/docs/concepts/architecture/cri.md | 31 ++ content/ru/docs/concepts/containers/_index.md | 33 ++ .../containers/container-environment.md | 51 +++ .../containers/container-lifecycle-hooks.md | 87 ++++++ content/ru/docs/concepts/containers/images.md | 294 ++++++++++++++++++ .../docs/concepts/containers/runtime-class.md | 131 ++++++++ .../glossary/container-runtime-interface.md | 18 ++ .../reference/glossary/container-runtime.md | 10 +- .../ru/docs/reference/glossary/namespace.md | 17 + content/ru/docs/reference/glossary/secret.md | 18 ++ .../reference/glossary/service-account.md | 18 ++ 11 files changed, 703 insertions(+), 5 deletions(-) create mode 100644 content/ru/docs/concepts/architecture/cri.md create mode 100644 content/ru/docs/concepts/containers/_index.md create mode 100644 content/ru/docs/concepts/containers/container-environment.md create mode 100644 content/ru/docs/concepts/containers/container-lifecycle-hooks.md create mode 100644 content/ru/docs/concepts/containers/images.md create mode 100644 content/ru/docs/concepts/containers/runtime-class.md create mode 100644 content/ru/docs/reference/glossary/container-runtime-interface.md create mode 100644 content/ru/docs/reference/glossary/namespace.md create mode 100644 content/ru/docs/reference/glossary/secret.md create mode 100644 content/ru/docs/reference/glossary/service-account.md diff --git a/content/ru/docs/concepts/architecture/cri.md b/content/ru/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000000..efa0708d75e17 --- /dev/null +++ b/content/ru/docs/concepts/architecture/cri.md @@ -0,0 +1,31 @@ +--- +title: Container Runtime Interface (CRI) +content_type: concept +weight: 50 +--- + + + +Интерфейс CRI позволяет kubelet работать с различными исполняемыми средами контейнеров без необходимости перекомпиляции компонентов кластера. + +{{}} должна работать на всех узлах кластера, чтобы {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} мог запускать {{< glossary_tooltip text="Pod'ы" term_id="pod" >}} и их контейнеры. + +{{< glossary_definition prepend="Интерфейс Kubernetes Container Runtime Interface (CRI)" term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet выступает в роли клиента при подключении к исполняемой среде через gRPC. Конечные точки ImageService и RuntimeService должны быть доступны в исполняемой среде контейнеров; в kubelet их можно настроить независимо с помощью [флагов командной строки](/docs/reference/command-line-tools-reference/kubelet) `--image-service-endpoint` и `--container-runtime-endpoint`. + +В Kubernetes v{{< skew currentVersion >}} kubelet предпочитает использовать CRI `v1`. Если исполняемая среда контейнера не поддерживает `v1` CRI, kubelet пытается перейти на более старую поддерживаемую версию. В версии v{{< skew currentVersion >}} kubelet также может работать с CRI `v1alpha2`, но эта версия считается устаревшей. Если согласовать поддерживаемую версию CRI не удается, узел не регистрируется. + +## Обновление + +При обновлении Kubernetes kubelet автоматически выбирает последнюю версию CRI при перезапуске компонента. Если это не удается, происходит откат, как описано выше. Если повторный вызов gRPC произошел из-за обновления исполняемой среды контейнера, последняя также должна поддерживать первоначально выбранную версию, иначе повторный вызов будет неудачным. Для этого требуется перезапуск kubelet'а. + +## {{% heading "whatsnext" %}} + +- Дополнительная информация о [протоколе CRI](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto) diff --git a/content/ru/docs/concepts/containers/_index.md b/content/ru/docs/concepts/containers/_index.md new file mode 100644 index 0000000000000..e04cb3cdb1898 --- /dev/null +++ b/content/ru/docs/concepts/containers/_index.md @@ -0,0 +1,33 @@ +--- +title: Контейнеры +weight: 40 +description: Технология упаковки приложения вместе с его runtime-зависимостями. +reviewers: +content_type: concept +no_list: true +--- + + + +Каждый запускаемый контейнер воспроизводим; стандартизация благодаря включению зависимостей позволяет каждый раз получать одинаковое поведение при запуске. + +Контейнеры абстрагируют приложения от базовой инфраструктуры хоста, упрощая развертывание в различных облачных средах или ОС. + + + + + + +## Образы контейнеров +[Образ контейнера](/docs/concepts/containers/images/) – это готовый к запуску пакет программного обеспечения, содержащий все необходимое для запуска приложения: код, среду исполнения, прикладные и системные библиотеки, а также значения по умолчанию всех важных параметров. + +Контейнер по определению неизменяем (immutable): код работающего контейнера невозможно поменять. Чтобы внести правки в контейнеризованное приложение, необходимо собрать новый образ, содержащий эти правки, а затем запустить контейнер на базе обновленного образа. + +## Исполняемые среды контейнеров + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* Раздел об [образах контейнеров](/docs/concepts/containers/images/). +* Раздел о [Pod'ах](/docs/concepts/workloads/pods/). diff --git a/content/ru/docs/concepts/containers/container-environment.md b/content/ru/docs/concepts/containers/container-environment.md new file mode 100644 index 0000000000000..465f841615453 --- /dev/null +++ b/content/ru/docs/concepts/containers/container-environment.md @@ -0,0 +1,51 @@ +--- +reviewers: +title: Контейнерное окружение +content_type: concept +weight: 20 +--- + + + +На этой странице описаны ресурсы, доступные для контейнеров в соответствующем окружении. + + + + + + +## Контейнерное окружение + +Контейнерное окружение Kubernetes предоставляет контейнерам несколько важных ресурсов: + +* Файловую систему, сочетающую в себе [образ](/docs/concepts/containers/images/) и один или несколько [томов](/docs/concepts/storage/volumes/). +* Информацию о самом контейнере. +* Информацию о других объектах в кластере. + +### Информация о контейнере + +*Hostname* контейнера — имя Pod'а, в котором запущен контейнер. Его можно получить с помощью команды `hostname` или функции [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) в libc. + +Имя Pod'а и его пространство имен можно получить из переменных окружения в [Downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). + +Контейнеру также доступны переменные окружения из определения Pod'а, заданные пользователем, а также любые переменные окружения, указанные статически в образе контейнера. + +### Информация о кластере + +Список всех сервисов, активных на момент создания контейнера, доступен этому контейнеру в виде переменных окружения. Этот список ограничен сервисами в пространстве имен, которому принадлежит Pod с данным контейнером, а также сервисами управляющего слоя Kubernetes. + +Для сервиса *foo*, связанного с контейнером *bar*, определены следующие переменные: + +```shell +FOO_SERVICE_HOST=<хост, на котором запущен сервис> +FOO_SERVICE_PORT=<порт, на котором запущен сервис> +``` + +Сервисы получают выделенные IP-адреса и доступны для контейнера через DNS, если включен [аддон DNS](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/). + + +## {{% heading "whatsnext" %}} + + +* [Хуки жизненного цикла контейнера](/docs/concepts/containers/container-lifecycle-hooks/). +* Упражнение: [Подключаем обработчики к событиям жизненного цикла контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/ru/docs/concepts/containers/container-lifecycle-hooks.md b/content/ru/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..78f6bce799595 --- /dev/null +++ b/content/ru/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,87 @@ +--- +reviewers: +- TBD +- TBD +title: Хуки жизненного цикла контейнеров +content_type: concept +weight: 30 +--- + + + +На этой странице описывается, как контейнеры под управлением kubelet могут использовать механизм хуков для запуска кода, инициированного событиями во время своего жизненного цикла. + + + + + + +## Общая информация + +Многие платформы для разработки предлагают хуки жизненного цикла компонентов (например, Angular). Kubernetes имеет аналогичный механизм. Хуки позволяют контейнерам оставаться в курсе событий своего жизненного цикла и запускать запакованный в обработчик код при наступлении определенных событий, приводящих к вызову хука. + +## Хуки контейнеров + +В распоряжении контейнеров имеются два хука: + +`PostStart` + +Выполняется сразу после создания контейнера. Однако нет гарантии, что хук закончит работу до ENTRYPOINT контейнера. Параметры обработчику не передаются. + +`PreStop` + +Вызывается непосредственно перед завершением работы контейнера в результате запроса API или иного события (например, неудачное завершение теста liveness/startup, вытеснение, борьба за ресурсы и т.п.). Вызов хука `PreStop` завершается неудачно, если контейнер уже находится в прерванном (terminated) или завершенном (completed) состоянии. Кроме того, работа хука должна закончиться до того, как будет отправлен сигнал TERM для остановки контейнера. Отсчет задержки перед принудительной остановкой Pod'а (grace-период) начинается до вызова хука `PreStop`. Таким образом, независимо от результата выполнения обработчика, контейнер будет остановлен в течение этого grace-периода. Параметры обработчику не передаются. + +Более подробное описание поведения при прекращении работы можно найти в разделе [Прекращение работы Pod'ов](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). + +### Реализации обработчиков хуков + +Чтобы контейнер имел доступ к хуку, необходимо реализовать и зарегистрировать обработчик для этого хука. Существует два типа обработчиков хуков, доступных для контейнеров: + +* Exec — Выполняет определенную команду, например, `pre-stop.sh`, внутри cgroups и пространств имен контейнера. Ресурсы, потребляемые командой, прибавляются к ресурсам, потребляемым контейнером. +* HTTP — Выполняет HTTP-запрос к определенной конечной точке контейнера. + +### Выполнение обработчиков хуков + +При вызове хука, привязанного к жизненному циклу контейнера, система управления Kubernetes выполняет обработчик в соответствии с типом хука: kubelet отвечает за `httpGet` и `tcpSocket`, а `exec` выполняется в контейнере. + +Вызовы обработчиков хуков синхронны в контексте Pod'а, содержащего контейнер. Это означает, что в случае `PostStart`-хука ENTRYPOINT контейнера и хук запускаются асинхронно. При этом если хук выполняется слишком долго или зависает, контейнер не может достичь состояния `Running`. + +Хуки `PreStop` не запускаются асинхронно с сигналом на остановку контейнера; хук должен завершить свою работу до отправки сигнала TERM. Если хук `PreStop` зависнет во время выполнения, Pod будет пребывать в состоянии `Terminating` до истечения периода `terminationGracePeriodSeconds`, после чего Kubernetes "убьет" его. Этот grace-период включает как время, которое требуется для выполнения хука `PreStop`, так и время, необходимое для нормальной остановки контейнера. Например, если `terminationGracePeriodSeconds` равен 60, работа хука занимает 55 секунд, а контейнеру требуется 10 секунд для нормальной остановки после получения сигнала, то контейнер будет "убит" до того, как сможет нормально завершить свою работу, поскольку `terminationGracePeriodSeconds` меньше, чем суммарное время (55+10), необходимое для работы хука и остановки контейнера. + +Если любой из хуков `postStart` / `preStop` завершается неудачей, Kubernetes "убивает" контейнер. + +Поэтому обработчики для хуков должны быть максимально простыми. Однако бывают случаи, когда применение "тяжелых" команд оправдано – например, при сохранении состояния перед остановкой контейнера. + +### Гарантии поставки хука + +Хук должен выполниться *хотя бы один раз*. Это означает, что он может вызываться неоднократно для любого события вроде `PostStart` или `PreStop`. Задача по правильной обработке подобных вызовов возложена на сам хук. + +Как правило, поставка хука выполняется однократно. Если, например, приемник HTTP-хука не работает и не может принимать трафик, повторная попытка отправки не предпринимается. В редких случаях может происходить двойная поставка. Например, если kubelet перезапустится в процессе доставки хука, тот может быть отправлен повторно. + +### Отладка обработчиков хуков + +Логи обработчиков хуков не отображаются в событиях Pod'а. В случае сбоя обработчика тот транслирует событие. Для `PostStart` это событие `FailedPostStartHook`, для `PreStop` — событие `FailedPreStopHook`. Чтобы самостоятельно сгенерировать событие `FailedPreStopHook`, в манифесте [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) замените команду для postStart на что-то заведомо невыполнимое (`badcommand`) и примените его. Если теперь выполнить команду `kubectl describe pod lifecycle-demo`, вы увидите следующее: + +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2... + Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms + Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx" + Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container + Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container + Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n" + Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook + Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms + Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container +``` + + + +## {{% heading "whatsnext" %}} + + +* Дополнительная информация о [контейнерном окружении](/docs/concepts/containers/container-environment/). +* Упражнение: [Подключаем обработчики к событиям жизненного цикла контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/ru/docs/concepts/containers/images.md b/content/ru/docs/concepts/containers/images.md new file mode 100644 index 0000000000000..3b78e08ed0512 --- /dev/null +++ b/content/ru/docs/concepts/containers/images.md @@ -0,0 +1,294 @@ +--- +reviewers: +title: Образы +content_type: concept +weight: 10 +--- + + + +Образ контейнера содержит исполняемые данные приложения и всех его программных зависимостей. Образы контейнеров — это исполняемые пакеты программного обеспечения, способные автономно работать и дополненные конкретными предположениями о соответствующей среде исполнения. + +Как правило, образ контейнера с приложением предварительно собирается и размещается в реестре, после чего его можно использовать в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}. + +На этой странице представлено общее описание концепции контейнерных образов. + + + +## Названия образов + +Образам контейнеров обычно присваивается имя, намекающее на их функционал и цели, например, `pause`, `example/mycontainer` или `kube-apiserver`. Образы также могут включать имя хоста реестра, например, `fictional.registry.example/imagename`, и (в некоторых случаях) номер порта, например, `fictional.registry.example:10443/imagename`. + +Если имя хоста реестра не указано, Kubernetes по умолчанию будет использовать публичный реестр Docker. + +После имени образа можно добавить _тег_ (как, например, в командах `docker` и `podman`). Теги помогают идентифицировать различные версии одной и той же линейки образов. + +Теги образов могут состоять из строчных и прописных букв, цифр, знаков подчеркивания (`_`), точек (`.`) и дефисов (`-`). +Кроме того, существуют дополнительные правила размещения символов-разделителей (`_`, `-` и `.`) внутри тега. +Если тег не указан, Kubernetes по умолчанию использует тег `latest`. + +## Обновление образов + +При первоначальном создании объекта типа {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod или другого объекта, включающего шаблон Pod'а, политика извлечения всех контейнеров в этом Pod'е будет по умолчанию установлена на `IfNotPresent`, если иное не указано явно. В рамках этой политики {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} не извлекает образ, если тот уже присутствует в кэше. + +### Политика извлечения образов + +Политика `imagePullPolicy` контейнера и тег образа определяют поведение [kubelet'а](/docs/reference/command-line-tools-reference/kubelet/) при извлечении (загрузке) данного образа. + +Вот список возможных значений `imagePullPolicy` и их влияние: + +`IfNotPresent` +: образ извлекается только в том случае, если он еще не доступен локально. + +`Always` +: каждый раз при запуске контейнера kubelet запрашивает [дайджест](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) образа в реестре образов контейнеров. Если полученный дайджест полностью совпадает с дайджестом кэшированного образа, kubelet использует кэшированный образ; иначе извлекается и используется образ с полученным дайждестом. + +`Never` +: kubelet не пытается скачать образ. Если образ уже присутствует локально, kubelet пытается запустить контейнер; в противном случае запуск завершается неудачей. Для получения более подробной информации обратитесь к разделу о [предварительно извлеченных](#предварительно-извлеченные-образы) (pre-pulled) образах. + +Благодаря семантике кэширования, лежащей в основе механизма поставки образов, даже `imagePullPolicy: Always` может быть вполне эффективной (при условии, что реестр надежно доступен). Исполняемая среда для контейнера может обнаружить, что слои образов уже имеются на узле и их не нужно скачивать еще раз. + +{{< note >}} +Избегайте использования тега `:latest` при развертывании контейнеров в production, поскольку в этом случае не понятно, какая именно версия образа используется и на какую ее нужно откатить при необходимости. + +Всегда указывайте содержательный тег, например `v1.42.0`. +{{< /note >}} + +Чтобы убедиться, что Pod всегда использует одну и ту же версию образа контейнера, можно указать дайджест образа вместо тега; для этого замените `:` на `@` +(например, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +Изменение кода, к которому привязан некий тег, может привести к тому, что в Pod'ах окажется две версии кода — старая и новая. Дайджест образа однозначно идентифицирует конкретную версию образа, что гарантирует идентичность кода при запуске контейнера с заданным именем образа и дайджестом. Таким образом, изменение кода в реестре уже не может привести к смешению версий. + +Существуют сторонние [admission-контроллеры](/docs/reference/access-authn-authz/admission-controllers/), которые модифицируют Pod'ы (и их шаблоны) при создании, из-за чего рабочая нагрузка определяется на основе дайджеста образа, а не тега. Это может быть полезно в случаях, когда необходимо убедиться, что вся рабочая нагрузка использует идентичный код независимо от изменений тегов в реестре. + +#### Политика извлечения образов по умолчанию {#imagepullpolicy-defaulting} + +Когда информация о новом Pod'е поступает на сервер API, кластер устанавливает поле `imagePullPolicy` в соответствии со следующими условиями: + + +- `imagePullPolicy` автоматически присваивается значение `Always`, если поле `imagePullPolicy` не задано, а тег для образа контейнера имеет значение `:latest`; +- `imagePullPolicy` автоматически присваивается значение `Always`, если поле `imagePullPolicy` не задано, а тег для образа контейнера не указан; +- `imagePullPolicy` автоматически присваивается значение `IfNotPresent`, если поле `imagePullPolicy` не задано, а тег для образа контейнера имеет значение, отличное от `:latest`. + +{{< note >}} +Значение `imagePullPolicy` контейнера всегда устанавливается при первом _создании_ объекта и не обновляется при последующем изменении тега образа. + +Например, если в Deployment'е используется образ с тегом, _отличным_ от `:latest`, а потом он меняется на `:latest`, поле `imagePullPolicy` останется прежним (т.е. _не_ будет изменено на `Always`). После первоначального создания любого объекта его политику извлечения можно изменить вручную. +{{< /note >}} + +#### Обязательное извлечение образов + +Для принудительного извлечения образов можно сделать следующее: + +- Установить `imagePullPolicy` контейнера в `Always`; +- Не устанавливать `imagePullPolicy` и использовать тег `:latest` для образа; Kubernetes автоматически поменяет политику на `Always`, получив информацию о Pod'е; +- Не устанавливать `imagePullPolicy` и тег образа; Kubernetes автоматически применит политику `Always`, получив информацию о Pod'е; +- Включить admission-контроллер [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + + +### ImagePullBackOff + +При создании kubelet'ом контейнеров для Pod'а может возникнуть ситуация, когда контейнер пребывает в состоянии [Waiting](/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) из-за `ImagePullBackOff`. + +Статус `ImagePullBackOff` означает, что контейнер не может запуститься, поскольку у Kubernetes не получается извлечь его образ (например, из-за ошибки в имени или попытки извлечь образ из приватного репозитория без `imagePullSecret`). `BackOff` в названии статуса указывает на то, что Kubernetes будет продолжать попытки извлечь образ, постепенно увеличивая интервал между ними. + +Так, интервал между попытками будет расти до тех пор, пока не достигнет установленного предела в 300 секунд (5 минут). + +## Мультиархитектурные образы с индексами + +Помимо обычных исполняемых образов реестр контейнеров также может хранить так называемые [индексы образов](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Индекс образа содержит ссылки на различные [манифесты образов](https://github.com/opencontainers/image-spec/blob/master/manifest.md), каждый из которых предназначен для определенной архитектуры. Идея здесь в том, чтобы любой пользователь мог получить образ, оптимизированный под конкретную архитектуру, используя его унифицированное, общее для всех архитектур имя (например, `pause`, `example/mycontainer`, `kube-apiserver`). + +Сам Kubernetes обычно добавляет суффикс `-$(ARCH)` к имени образа. Для обратной совместимости также рекомендуется генерировать образы с суффиксами в названиях. Например, универсальный образ `pause`, содержащий манифест для всех архитектур, рекомендуется дополнить образом `pause-amd64` для обратной совместимости со старыми конфигурациями или YAML-файлами, в которых могут быть жестко прописаны образы с суффиксами. + +## Работа с приватным реестром + +Для чтения образов из приватных реестров могут потребоваться соответствующие ключи. +Доступ к таким реестрам можно получить следующими способами: + - Аутентификация на уровне узлов: + - все Pod'ы имеют доступ ко всем настроенным приватным реестрам; + - требуется конфигурация узлов администратором кластера; + - Предварительно извлеченные образы: + - все Pod'ы могут использовать любые образы, кэшированные на узле; + - для настройки требуется root-доступ ко всем узлам; + - imagePullSecrets на уровне Pod'а: + - доступ к реестру получают только Pod'ы с ключами; + - Специализированные расширения от вендора/пользователя: + - в кастомных конфигурациях могут существовать специализированные механизмы аутентификации узлов в реестре контейнеров, реализованные самим пользователем или поставщиком облачных услуг. + +Ниже мы подробнее остановимся на каждом из вариантов. + +### Аутентификация на уровне узлов + +Конкретные инструкции по настройке учетных данных зависят от среды исполнения контейнера и реестра. Для получения наиболее подробной информации следует обратиться к документации используемого решения. + +Пример настройки частного реестра образов контейнеров приводится в упражнении [Извлекаем образ из частного реестра](/docs/tasks/configure-pod-container/pull-image-private-registry). В нем используется частный реестр в Docker Hub. + +### Интерпретация config.json {#config-json} + +Интерпретация `config.json` отличается в оригинальной Docker-реализации и в Kubernetes. В Docker ключи `auths` могут указывать только корневые URL, в то время как Kubernetes позволяет использовать URL с подстановками (globbing) и пути с префиксами. То есть `config.json`, подобный этому, вполне допустим: + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +Корневой URL (`*my-registry.io`) сопоставляется с помощью следующего синтаксиса: + +``` +pattern: + { term } + +term: + '*' соответствует любой последовательности символов, не являющихся разделителями + '?' соответствует любому одиночному символу, не являющемуся разделителем + '[' [ '^' ] { диапазон символов } ']' + класс символов (не может быть пустым) + c соответствует символу c (c != '*', '?', '\\', '[') + '\\' c соответствует символу c + +диапазон символов: + c соответствует символу c (c != '\\', '-', ']') + '\\' c соответствует символу c + lo '-' hi соответствует символу c при lo <= c <= hi +``` + +Учетные данные теперь будут передаваться в CRI-совместимую исполняемую среду для контейнеров для каждого действительного шаблона. Ниже приведены примеры имен образов, удовлетворяющие требованиям к паттерну: + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet последовательно извлекает образы для каждой обнаруженной учетной записи. Это означает, что `config.json` может содержать сразу несколько записей: + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +К примеру, если необходимо извлечь образ `my-registry.io/images/subpath/my-image`, kubelet будет пытаться загрузить его из второго источника, если первый не работает. + +### Предварительно извлеченные образы + +{{< note >}} +Этот подход применим, если имеется доступ к конфигурации узлов. Он не будет надежно работать, если поставщик облачных услуг управляет узлами и автоматически заменяет их. +{{< /note >}} + +По умолчанию kubelet пытается извлечь каждый образ из указанного реестра. Однако если параметр `imagePullPolicy` контейнера установлен на `IfNotPresent` или `Never`, используется локальный образ (преимущественно или исключительно, соответственно). + +Чтобы использовать предварительно извлеченные образы (и не связываться с аутентификацией для доступа к реестру), необходимо убедиться, что они идентичны на всех узлах кластера. + +Предварительная загрузка образов позволяет увеличить скорость работы и является альтернативой аутентификации в приватном реестре. + +При этом у всех Pod'ов будет доступ на чтение всех предварительно извлеченных образов. + +### Задаем imagePullSecrets на уровне Pod'а + +{{< note >}} +Это рекомендуемый подход для запуска контейнеров на основе образов в приватных реестрах. +{{< /note >}} + +Kubernetes поддерживает указание ключей реестра образов на уровне Pod'а. + +#### Создаем Secret с помощью конфигурационного файла Docker + +Для аутентификации в реестре необходимо знать имя пользователя, пароль, имя хоста реестра и адрес электронной почты клиента. + +Выполните следующую команду, подставив соответствующие значения вместо параметров, выделенных заглавными буквами: + +```shell +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL +``` + +При наличии файла учетных данных Docker можно импортировать их как {{< glossary_tooltip text="Secret'ы" term_id="secret" >}} Kubernetes вместо команды, приведенной выше. + +В разделе [Создание Secret'а на основе существующих учетных данных Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) рассказывается, как это можно сделать. + +Это особенно удобно в случае нескольких приватных реестров контейнеров, так как `kubectl create secret docker-registry` создает Secret, который работает только с одним приватным реестром. + +{{< note >}} +Pod'ы могут работать только с Secret'ами в собственном пространстве имен, поэтому данный процесс необходимо повторить для каждого пространства имен. +{{< /note >}} + +#### Ссылаемся на imagePullSecrets в Pod'е + +Теперь можно создавать Pod'ы, ссылающиеся на данный Secret, добавив раздел `imagePullSecrets` в манифест Pod'а. + +Например: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Это необходимо проделать для каждого Pod'а, работающего с приватным репозиторием. + +Процесс можно автоматизировать, задав imagePullSecrets в ресурсе [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). + +Подробные инструкции см. в разделе [Добавить ImagePullSecrets в Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). + +Этот подход можно использовать совместно с файлами `.docker/config.json`, определяемыми для каждого узла. Учетные данные будут объединены. + +## Примеры использования + +Существует ряд решений для настройки приватных реестров. Вот некоторые распространенные случаи использования и рекомендуемые решения: + +1. Кластер, работающий только со свободными (например, Open Source) образами. Необходимость скрывать образы отсутствует. + - Используйте общедоступные образы из Docker Hub; + - Настройка не требуется; + - Некоторые облачные провайдеры автоматически кэшируют или зеркалируют публичные образы, что повышает доступность и сокращает время их извлечения. +1. В кластере используются закрытые образы. Они должны быть скрыты для всех за пределами компании, но доступны для всех пользователей кластера. + - Используйте приватный репозиторий; + - Может потребоваться ручная настройка на узлах, которым необходим доступ к частному репозиторию; + - В качестве альтернативы можно завести внутренний приватный реестр с доступом на чтение, скрыв его за сетевым экраном; + - Настройка Kubernetes не требуется; + - Используйте сервис для работы с образами, контролирующий доступ к ним; + - Этот подход лучше работает с автомасштабированием кластера, нежели ручная настройка узлов; + - Если изменение конфигурации узлов в кластере затруднено, можно использовать imagePullSecrets. +1. Кластер с несвободными образами, некоторые из которых требуют более строгого контроля доступа. + - Убедитесь, что [AlwaysPullImages admission-контроллер](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) включен. В противном случае у всех Pod'ов потенциально будет доступ ко всем образам; + - Переместите конфиденциальные данные в Secret вместо того, чтобы упаковывать их в образ. +1. Кластер категории multi-tenant (многопользовательский), где каждому пользователю требуется собственный приватный репозиторий. + - Убедитесь, что [admission-контроллер AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) включен. В противном случае у всех Pod'ов всех пользователей потенциально будет доступ ко всем образам; + - Создайте приватный реестр с обязательной авторизацией; + - Сгенерируйте учетные данные для доступа к реестру для каждого пользователя, поместите их в Secret и добавьте его в пространство имен каждого пользователя; + - Каждый пользователь должен добавить свой Secret в imagePullSecrets каждого пространства имен. + + +Если нужен доступ к нескольким реестрам, можно создать по Secret'у для каждого реестра. + +## {{% heading "whatsnext" %}} + +* [Спецификация манифестов образов OCI](https://github.com/opencontainers/image-spec/blob/master/manifest.md). +* Сборка "мусора" в Kubernetes — [неиспользуемые контейнеры и образы](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). +* [Извлечение образов из приватных репозиториев](/docs/tasks/configure-pod-container/pull-image-private-registry). diff --git a/content/ru/docs/concepts/containers/runtime-class.md b/content/ru/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000000..7169da2868f73 --- /dev/null +++ b/content/ru/docs/concepts/containers/runtime-class.md @@ -0,0 +1,131 @@ +--- +reviewers: +title: RuntimeClass +content_type: concept +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +На этой странице описывается ресурс RuntimeClass и механизм выбора исполняемой среды. + +RuntimeClass позволяет выбрать конфигурацию исполняемой среды для контейнеров. Используется для настройки исполняемой среды в Pod'е. + + + +## Мотивация + +Разным Pod'ам можно назначать различные RuntimeClass'ы, соблюдая баланс между производительностью и безопасностью. Например, если часть рабочей нагрузки требует высокого уровня информационной безопасности, связанные с ней Pod'ы можно запланировать так, чтобы они использовали исполняемую среду для контейнеров на основе аппаратной виртуализации. Это обеспечит повышенную изоляцию, но потребует дополнительных издержек. + +Также можно использовать RuntimeClass для запуска различных Pod'ов с одинаковой исполняемой средой, но с разными настройками. + +## Подготовка + +1. Настройте реализацию CRI на узлах (зависит от используемой исполняемой среды); +2. Создайте соответствующие ресурсы RuntimeClass. + +### 1. Настройте реализацию CRI на узлах + +Конфигурации, доступные с помощью RuntimeClass, зависят от реализации Container Runtime Interface (CRI). Для настройки определенной реализации CRI обратитесь к соответствующему разделу документации ([ниже](#cri-configuration)). + +{{< note >}} +По умолчанию RuntimeClass предполагает однородную конфигурацию узлов в кластере (то есть все узлы настроены одинаково в плане исполняемой среды для контейнеров). Для гетерогенных конфигураций узлов см. раздел [Scheduling](#scheduling) ниже. +{{< /note >}} + +Каждой конфигурации соответствует обработчик, на который ссылается RuntimeClass. Имя обработчика должно соответствовать [синтаксису для меток DNS](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + +### 2. Создайте соответствующие ресурсы RuntimeClass + +К каждой конфигурации, настроенной на шаге 1, должно быть привязано имя обработчика (`handler`), которое ее идентифицирует. Для каждого обработчика создайте соответствующий объект RuntimeClass. + +На данный момент у ресурса RuntimeClass есть только 2 значимых поля: имя RuntimeClass (`metadata.name`) и обработчик (`handler`). Определение объекта выглядит следующим образом: + +```yaml +# RuntimeClass определен в API-группе node.k8s.io +apiVersion: node.k8s.io/v1 +kind: RuntimeClass +metadata: + # Имя, которое ссылается на RuntimeClass + # ресурс RuntimeClass не включается в пространство имен + name: myclass +# Имя соответствующей конфигурации CRI +handler: myconfiguration +``` + +Имя объекта RuntimeClass должно удовлетворять [синтаксису для поддоменных имен DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +{{< note >}} +Рекомендуется ограничить доступ к операциям записи RuntimeClass (create/update/patch/delete) администратором кластера. Обычно это сделано по умолчанию. Более подробную информацию см. в разделе [Общая информация об авторизации](/docs/reference/access-authn-authz/authorization/). +{{< /note >}} + +## Использование + +После того как RuntimeClasses настроены для кластера, использовать их очень просто. Достаточно указать `runtimeClassName` в спецификации Pod'а. Например: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +kubelet будет использовать указанный RuntimeClass для запуска этого Pod'а. Если указанный RuntimeClass не существует или CRI не может запустить соответствующий обработчик, Pod войдет в [фазу завершения работы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Полное сообщение об ошибке можно получить, обратившись к соответствующему [событию](/docs/tasks/debug/debug-application/debug-running-pod/) (event). + +Если имя `runtimeClassName` не указано, будет использоваться RuntimeHandler по умолчанию (что эквивалентно поведению, когда функция RuntimeClass отключена). + +### Настройка CRI + +Для получения более подробной информации о настройке исполняемых сред CRI обратитесь к разделу [Установка CRI](/docs/setup/production-environment/container-runtimes/). + +#### {{< glossary_tooltip term_id="containerd" >}} + +Обработчики исполняемой среды настраиваются в конфигурации containerd в файле `/etc/containerd/config.toml`. Допустимые обработчики прописываются в разделе runtimes: + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] +``` + +Дополнительная информация доступна в [документации по конфигурации containerd](https://github.com/containerd/cri/blob/master/docs/config.md). + +#### {{< glossary_tooltip term_id="cri-o" >}} + +Обработчики исполняемой среды настраиваются в файле конфигурации CRI-O (`/etc/crio/crio.conf`). Допустимые обработчики прописываются в [таблице crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +Более подробную информацию см. в [документации по конфигурации CRI-O](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md). + +## Scheduling + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Поле `scheduling` в RuntimeClass позволяет наложить определенные ограничения, гарантировав, что Pod'ы с определенным RuntimeClass'ом будут планироваться на узлы, которые его поддерживают. Если параметр `scheduling` не установлен, предполагается, что данный RuntimeClass поддерживается всеми узлами. + +Чтобы гарантировать, что Pod'ы попадают на узлы, поддерживающие определенный RuntimeClass, эти узлы должны быть связаны общей меткой, которая затем выбирается полем `runtimeclass.scheduling.nodeSelector`. nodeSelector RuntimeClass'а объединяется с nodeSelector'ом admission-контроллера, на выходе образуя пересечение подмножеств узлов, выбранных каждым из селекторов. Если возникает конфликт, Pod отклоняется. + +Если поддерживаемые узлы объединены неким taint'ом, чтобы предотвратить запуск на них Pod'ов с другими RuntimeClass'ами, можно к нужному RuntimeClass'у добавить `tolerations`. Как и в случае с `nodeSelector`, tolerations объединяются с tolerations Pod'а admission-контроллера, фактически образуя объединение двух подмножеств узлов с соответствующими tolerations. + +Чтобы узнать больше о настройке селектора узлов и tolerations, см. раздел [Назначаем Pod'ы на узлы](/docs/concepts/scheduling-eviction/assign-pod-node/). + +### Pod Overhead + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Можно указать _overhead_-ресурсы, необходимые для работы Pod'а. Это позволит кластеру (и планировщику) учитывать их при принятии решений о Pod'ах и управлении ресурсами. + +В RuntimeClass дополнительные ресурсы, потребляемые Pod'ом, указываются в поле `overhead`. С помощью этого поля можно указать ресурсы, необходимые Pod'ам с данным RuntimeClass'ом, и гарантировать их учет в Kubernetes. + +## {{% heading "whatsnext" %}} + +- Описание [RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md); +- Описание [RuntimeClass Scheduling](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling); +- Концепция [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/); +- Описание функции [PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead). diff --git a/content/ru/docs/reference/glossary/container-runtime-interface.md b/content/ru/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000000..8bb24114a029f --- /dev/null +++ b/content/ru/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,18 @@ +--- +title: Container Runtime Interface +id: container-runtime-interface +date: 2021-11-24 +full_link: /docs/concepts/architecture/cri +short_description: > + Основной протокол для связи между kubelet'ом и исполняемой средой контейнеров. + +aka: +tags: + - cri +--- + +Container Runtime Interface (CRI) — это основной протокол для связи между kubelet'ом и исполняемой средой контейнеров. + + + +Интерфейс Kubernetes Container Runtime Interface (CRI) задает основной [gRPC-протокол](https://grpc.io), на базе которого осуществляется коммуникация между [компонентами кластера](/docs/concepts/overview/components/#node-components): {{< glossary_tooltip text="kubelet'ом" term_id="kubelet" >}} и {{< glossary_tooltip text="исполняемой средой" term_id="container-runtime" >}}. diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index 25916582e51ef..0ff3f1c47d574 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -1,21 +1,21 @@ --- -title: Среда выполнения контейнера +title: Иполняемая среда контейнеров id: container-runtime date: 2019-06-05 full_link: /docs/setup/production-environment/container-runtimes short_description: > - Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. + Иполняемая среда контейнеров — это программа, предназначенная для запуска контейнеров. aka: tags: - fundamental - workload --- - Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. + Иполняемая среда контейнера — это программа, предназначенная для запуска контейнера в Kubernetes. -Kubernetes поддерживает несколько сред для запуска контейнеров: {{< glossary_tooltip term_id="docker">}}, +Kubernetes поддерживает различные среды для запуска контейнеров: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, -и любая реализация [Kubernetes CRI (Container Runtime +и любые реализации [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/ru/docs/reference/glossary/namespace.md b/content/ru/docs/reference/glossary/namespace.md new file mode 100644 index 0000000000000..9e876227cdfe6 --- /dev/null +++ b/content/ru/docs/reference/glossary/namespace.md @@ -0,0 +1,17 @@ +--- +title: Пространство имен +id: namespace +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/namespaces +short_description: > + Абстракция, которую Kubernetes использует для изоляции групп ресурсов в рамках одного кластера. + +aka: +tags: +- fundamental +--- + Абстракция, которую Kubernetes использует для изоляции групп ресурсов в рамках одного {{< glossary_tooltip text="кластера" term_id="cluster" >}}. + + + +Пространства имен используются для организации объектов в кластере и разграничивают ресурсы кластера. Имена ресурсов должны быть уникальными в пределах одного пространства имен, но не в разных пространствах имен. Ограничения на основе пространства имен применимы только к объектам на уровне пространств имен _(например, Deployments, Services и т.д.)_, но не для объектов на уровне кластера _(таких как StorageClass, Nodes, PersistentVolumes и т.д.)_. diff --git a/content/ru/docs/reference/glossary/secret.md b/content/ru/docs/reference/glossary/secret.md new file mode 100644 index 0000000000000..4abf91292d024 --- /dev/null +++ b/content/ru/docs/reference/glossary/secret.md @@ -0,0 +1,18 @@ +--- +title: Secret +id: secret +date: 2018-04-12 +full_link: /docs/concepts/configuration/secret/ +short_description: > + Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh. + +aka: +tags: +- core-object +- security +--- + Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh. + + + +Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на шифрование "at rest" (при записи в хранилище). {{< glossary_tooltip text="Pod" term_id="pod" >}} ссылается на Secret как на файл при монтировании тома. Secret также используется kubelet'ом при извлечении образов для Pod'а. Secret'ы отлично подходят для хранения конфиденциальных данных, [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) – для неконфиденциальных. diff --git a/content/ru/docs/reference/glossary/service-account.md b/content/ru/docs/reference/glossary/service-account.md new file mode 100644 index 0000000000000..87abd6a1935da --- /dev/null +++ b/content/ru/docs/reference/glossary/service-account.md @@ -0,0 +1,18 @@ +--- +title: ServiceAccount +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + Отвечает за идентификацию процессов, выполняющихся в Pod'е. + +aka: +tags: +- fundamental +- core-object +--- + Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}. + + + +Процессы внутри Pod'а аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании Pod'а служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}. From 4f3f22403002b1a31d0dc927fcfb64349be55690 Mon Sep 17 00:00:00 2001 From: Kirill Kononovich <41591254+kirkonru@users.noreply.github.com> Date: Tue, 13 Sep 2022 18:00:27 +0300 Subject: [PATCH 009/215] Add RU localization for system-logs.md Apply suggestions from code review Co-authored-by: Tim Bannister Co-authored-by: Dmitry Shurupov --- .../cluster-administration/system-logs.md | 185 ++++++++++++++++++ 1 file changed, 185 insertions(+) create mode 100644 content/ru/docs/concepts/cluster-administration/system-logs.md diff --git a/content/ru/docs/concepts/cluster-administration/system-logs.md b/content/ru/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000000..3c108e0461b58 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,185 @@ +--- +title: Логи системных компонентов +content_type: concept +weight: 60 +--- + + + +Логи системных компонентов регистрируют события, происходящие в кластере, что может быть очень полезно при отладке. Степень детализации логов настраивается. Так, в логах низкой детализации будет содержаться только информация об ошибках внутри компонента, в то время как логи высокой детализации будут содержать пошаговую трассировку событий (доступ по HTTP, изменения состояния Pod'а, действия контроллера, решения планировщика). + + + +## Klog + +[klog](https://github.com/kubernetes/klog) — библиотека Kubernetes для сбора логов. Отвечает за генерацию соответствующих сообщений для системных компонентов оркестратора. + +Дополнительные сведения о настройке klog можно получить в [Справке по CLI](/docs/reference/command-line-tools-reference/). + +В настоящее время ведется работа по упрощению процесса сбора логов в компонентах Kubernetes. Приведенные ниже флаги командной строки klog [устарели](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components), начиная с версии Kubernetes 1.23, и будут удалены в одном из будущих релизов: + +- `--add-dir-header` +- `--alsologtostderr` +- `--log-backtrace-at` +- `--log-dir` +- `--log-file` +- `--log-file-max-size` +- `--logtostderr` +- `--one-output` +- `--skip-headers` +- `--skip-log-headers` +- `--stderrthreshold` + +Вывод всегда будет записываться в stderr независимо от его формата. Перенаправление вывода должно осуществляться компонентом, который вызывает компонент Kubernetes, например, POSIX-совместимой командной оболочкой или инструментом вроде systemd. + +Иногда эти опции недоступны — например, в случае контейнера без дистрибутива (distroless) или системной службы Windows. Тогда [`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md) можно использовать в качестве обертки вокруг компонента Kubernetes для перенаправления вывода. Его предварительно собранный исполняемый файл включен в некоторые базовые образы Kubernetes под старым именем `/go-runner`, а в актуальных бинарных релизах архивов с kubernetes-server и kubernetes-node он называется `kube-log-runner`. + +В таблице ниже показаны соответствия между вызовами `kube-log-runner` и логикой перенаправления командной оболочки: + +| Использование | Оболочка POSIX (например, Bash) | `kube-log-runner ` | +| ---------------------------------------------|---------------------------------|---------------------------------------------------------------| +| Объединить stderr и stdout, вывести в stdout | `2>&1` | `kube-log-runner` (default behavior) | +| Перенаправить оба потока в файл лога | `1>>/tmp/log 2>&1` | `kube-log-runner -log-file=/tmp/log` | +| Скопировать в файл лога и в stdout | `2>&1 \| tee -a /tmp/log` | `kube-log-runner -log-file=/tmp/log -also-stdout` | +| Перенаправить только stdout в файл лога | `>/tmp/log` | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` | + +### Вывод klog + +Пример оригинального "родного" формата klog: +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +Сообщение может содержать переносы строк: +``` +I1025 00:15:15.525108 1 example.go:79] This is a message +which has a line break. +``` + + +### Структурированное логирование + +{{< feature-state for_k8s_version="v1.23" state="beta" >}} + +{{< warning >}} +Переход на структурированное логирование — продолжающийся процесс. Не все сообщения структурированы в текущей версии Kubernetes. При парсинге файлов логов необходимо также обрабатывать неструктурированные сообщения. + +Формат логов и сериализация значений могут измениться в будущем. +{{< /warning>}} + +Структурированное логирование придает определенную структуру сообщениям логов, упрощая программное извлечение информации и сокращая затраты и усилия на их обработку. Код, который генерирует сообщение лога, определяет, используется ли обычный неструктурированный вывод klog или структурированное логирование. + +По умолчанию структурированные сообщения форматируются как текст, при этом его формат обратно совместим с традиционным форматом klog: + +```ini + "" ="" ="" ... +``` + +Пример: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + +Строки заключаются в кавычки. Другие значения форматируются с помощью [`%+v`](https://pkg.go.dev/fmt#hdr-Printing). В результате сообщение может продолжиться на следующей строке в [зависимости от типа данных](https://github.com/kubernetes/kubernetes/issues/106428). + +``` +I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line, +second line.} +``` + +### Контекстное логирование + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + +Контекстное логирование базируется на структурированном логировании. Речь идет в первую очередь о том, как разработчики используют лог-вызовы: код, основанный на этой концепции, более гибок и поддерживает дополнительные сценарии использования (см. [Contextual Logging KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)). + +При использовании в компонентах дополнительных функций, таких как `WithValues` или `WithName`, записи лога содержат дополнительную информацию, которая передается в функции вызывающей стороной. + +В настоящее время за включение контекстного логирования отвечает переключатель функционала `StructuredLogging`. По умолчанию оно отключено. Соответствующая инфраструктура появилась в версии 1.24 и она не потребовала изменений в компонентах. Команда [`component-base/logs/example`](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go) показывает, как использовать новые лог-вызовы и как ведет себя компонент, поддерживающий контекстное логирование. + +```console +$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/ +$ go run . --help +... + --feature-gates mapStringBool A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: + AllAlpha=true|false (ALPHA - default=false) + AllBeta=true|false (BETA - default=false) + ContextualLogging=true|false (ALPHA - default=false) +$ go run . --feature-gates ContextualLogging=true +... +I0404 18:00:02.916429 451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s" +I0404 18:00:02.916447 451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s" +``` + +Префикс `example` и `foo="bar"` были добавлены вызовом функции, которая пишет в лог сообщение `runtime` и значение `duration="1m0s"`, при этом вносить изменения в эту функцию не потребовалось. + +При отключенном контекстном логировании `WithValues` и `WithName` ничего не делают, а вызовы журнала проходят через глобальный логгер klog. Соответственно, эта дополнительная информация более не отображается в логе: + +```console +$ go run . --feature-gates ContextualLogging=false +... +I0404 18:03:31.171945 452150 logger.go:94] "runtime" duration="1m0s" +I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s" +``` + +### Логи в формате JSON + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +Вывод в формате JSON не поддерживает многие стандартные флаги klog. Список неподдерживаемых флагов klog см. в [Справочнике по CLI](/docs/reference/command-line-tools-reference/). + +Кроме того, запись в формате JSON не гарантируется (например, во время запуска процесса). Таким образом, если планируется дальнейший парсинг логов, убедитесь, что ваш парсер способен обрабатывать строки лога, которые не являются JSON. + +Имена полей и сериализация JSON могут измениться в будущем. +{{< /warning >}} + +Флаг `--logging-format=json` переключает формат логов с родного формата klog на JSON. Пример лога в формате JSON (стилистически отформатированном): +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +Специальные ключи: +* `ts` — временная метка в формате времени Unix (обязательный параметр, float); +* `v` — детализация (для общей информации — не для сообщений об ошибках, int); +* `err` — ошибка (опциональный параметр, string); +* `msg` — сообщение (обязательный параметр, string). + + +Список компонентов, поддерживающих формат JSON: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### Уровень детализации лога + +Флаг `-v` задает степень детализации лога. Увеличение значения увеличивает количество регистрируемых событий. Уменьшение значения уменьшает количество регистрируемых событий. Увеличение детализации приводит к тому, что регистрируются все менее значимые события. При уровне детализации, равном 0, регистрируются только критические события. + +### Местоположение лога + +Существует два типа системных компонентов: те, которые работают в контейнере, и те, которые работают за пределами контейнера. Например: + +* Планировщик Kubernetes и kube-proxy работают в контейнере. +* kubelet и {{}} + работают за пределами контейнеров. + +На машинах с systemd среда исполнения и kubelet пишут в journald. В противном случае ведется запись в файлы `.log` в директории `/var/log`. Системные компоненты внутри контейнеров всегда пишут в файлы `.log` в директории `/var/log`, обходя механизм логирования по умолчанию. Как и логи контейнеров, логи системных компонентов в `/var/log` нуждаются в ротации. В кластерах Kubernetes, созданных с использованием скрипта `kube-up.sh`, ротация логов настраивается с помощью инструмента `logrotate`. `logrotate` ротирует логи ежедневно или при достижении ими размера в 100 МБ. + +## {{% heading "whatsnext" %}} + +* [Архитектура логирования в Kubernetes](/docs/concepts/cluster-administration/logging/) +* [Структурированное логирование (EN)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) +* [Контекстное логирование (EN)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) +* [Вывод флагов klog из эксплуатации (EN)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +* [Соглашения и правила для определения критичности логов (EN)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) From 9f485e7fa6247067b492e15f955325367a6750f9 Mon Sep 17 00:00:00 2001 From: Kinzhi Date: Tue, 21 Feb 2023 00:48:54 +0800 Subject: [PATCH 010/215] [zh-cn]SYNC generate-ref-docs/_index.md --- content/zh-cn/docs/contribute/generate-ref-docs/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/_index.md b/content/zh-cn/docs/contribute/generate-ref-docs/_index.md index 87f08c5f6d75a..9a4d18bcbc5ca 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/_index.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/_index.md @@ -1,11 +1,11 @@ --- -title: 参考文档概述 +title: 更新参考文档 main_menu: true weight: 80 --- From d1be50d94e2c7e3655c4ff71bbe7a4c0d0dca343 Mon Sep 17 00:00:00 2001 From: Ana Carolina Rodrigues Date: Tue, 21 Feb 2023 14:10:25 -0300 Subject: [PATCH 011/215] Update content/pt-br/docs/reference/issues-security.md --- content/pt-br/docs/reference/issues-security/issues.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt-br/docs/reference/issues-security/issues.md b/content/pt-br/docs/reference/issues-security/issues.md index 706a69f5fd0c8..c1c8584739491 100644 --- a/content/pt-br/docs/reference/issues-security/issues.md +++ b/content/pt-br/docs/reference/issues-security/issues.md @@ -8,9 +8,9 @@ Para reportar um problema de segurança, siga [processo de divulgação de issue O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando [ GitHub Issues ](https://github.com/kubernetes/kubernetes/issues/). -* Oficial [lista de CVEs conhecidos](/docs/reference/issues-security/official-cve-feed/) +* Lista [oficial de CVEs conhecidos](/docs/reference/issues-security/official-cve-feed/) (vulnerabilidades de segurança) que foram anunciados pelo [comitê de resposta de segurança](https://github.com/kubernetes/committee-security-response) -* [Problemas do gitHub relacionados ao CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) +* [Questões relacionadas ao CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) Anúncios relacionados à segurança são enviados para a lista de discussão [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce). \ No newline at end of file From 6f330b23df05b446c0115aa23618f378336dd5c0 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Wed, 22 Feb 2023 10:20:20 -0500 Subject: [PATCH 012/215] [pt-br] Update enforce-standards-admission-controller.md. * Update the contents in the Brazilian Portuguese version of docs/tasks/configure-pod-container/enforce-standards-admission-controller.md to reflect the latest English content. --- .../enforce-standards-admission-controller.md | 90 +++++++------------ 1 file changed, 31 insertions(+), 59 deletions(-) diff --git a/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md b/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md index 7762fc1cf5581..d3eb331c5d91c 100644 --- a/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md +++ b/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md @@ -1,43 +1,53 @@ --- title: Aplicando os Padrões de Segurança do Pod Através da Configuração do Controlador de Admissão Embutido content_type: task -min-kubernetes-server-version: v1.22 --- -Desde a versão v1.22, o Kubernetes fornece um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) -embutido para fazer cumprir os [padrões de segurança do Pod](/docs/concepts/security/pod-security-standards). -Você pode configurar esse controlador de admissão para definir padrões em todo -o cluster e [exceções](/docs/concepts/security/pod-security-admission/#exemptions). +O Kubernetes force um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +embutido para garantir os [padrões de segurança do Pod](/docs/concepts/security/pod-security-standards). +Você pode configurar esse controlador de admissão para definir padrões e +[isenções](/docs/concepts/security/pod-security-admission/#exemptions) em todo +o cluster. ## {{% heading "prerequisites" %}} +Após uma release alfa no Kubernetes v1.22, o controlador de admissão +_Pod Security Admission_ tornou-se disponível por padrão no Kubernetes v1.23, +no estado beta. Da versão 1.25 em diante o controlador de admissão _Pod Security +Admission_ está publicamente disponível. + {{% version-check %}} -- Garanta que a `PodSecurity` do [`feature gate`](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) -está ativada. +Se você não estiver utilizando o Kubernetes {{< skew currentVersion >}}, você +pode verificar a documentação da versão do Kubernetes que você está utilizando. ## Configure o Controlador de Admissão -{{< tabs name="PodSecurityConfiguration_example_1" >}} -{{% tab name="pod-security.admission.config.k8s.io/v1beta1" %}} +{{< note >}} +A configuração `pod-security.admission.config.k8s.io/v1` requer o Kubernetes v1.25 +ou superior. +Para as versões v1.23 e v1.24, utilize [v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/). +Para a versão v1.22, utilize [v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/). +{{< /note >}} + ```yaml -apiVersion: apiserver.config.k8s.io/v1 +apiVersion: apiserver.config.k8s.io/v1 # veja a nota de compatibilidade kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: apiVersion: pod-security.admission.config.k8s.io/v1beta1 kind: PodSecurityConfiguration - # Defaults applied when a mode label is not set. + # Padrões aplicados quando o label de modo não é especificado. # - # Level label values must be one of: - # - "privileged" (default) + # O valor para o label Level deve ser uma das opções abaixo: + # - "privileged" (padrão) # - "baseline" # - "restricted" # - # Version label values must be one of: - # - "latest" (default) - # - specific version like "v{{< skew currentVersion >}}" + # O valor para o label Version deve ser uma das opções abaixo: + # - "latest" (padrão) + # - versão específica no formato "v{{< skew currentVersion >}}" defaults: enforce: "privileged" enforce-version: "latest" @@ -46,53 +56,15 @@ plugins: warn: "privileged" warn-version: "latest" exemptions: - # Array of authenticated usernames to exempt. + # Lista de usuários autenticados a eximir. usernames: [] - # Array of runtime class names to exempt. + # Lista de RuntimeClasses a eximir. runtimeClasses: [] - # Array of namespaces to exempt. + # Lista de namespaces a eximir. namespaces: [] ``` {{< note >}} -A versão da configuração v1beta1 requer a versão v1.23 ou superior do Kubernetes. Para a versão v1.22 do Kubernetes, utilize v1alpha1. +O manifesto acima precisa ser especificado através da opção de linha de comando +`--admission-control-config-file` do kube-apiserver. {{< /note >}} - -{{% /tab %}} -{{% tab name="pod-security.admission.config.k8s.io/v1alpha1" %}} - -```yaml -apiVersion: apiserver.config.k8s.io/v1 -kind: AdmissionConfiguration -plugins: -- name: PodSecurity - configuration: - apiVersion: pod-security.admission.config.k8s.io/v1alpha1 - kind: PodSecurityConfiguration - # Defaults applied when a mode label is not set. - # - # Level label values must be one of: - # - "privileged" (default) - # - "baseline" - # - "restricted" - # - # Version label values must be one of: - # - "latest" (default) - # - specific version like "v{{< skew currentVersion >}}" - defaults: - enforce: "privileged" - enforce-version: "latest" - audit: "privileged" - audit-version: "latest" - warn: "privileged" - warn-version: "latest" - exemptions: - # Array of authenticated usernames to exempt. - usernames: [] - # Array of runtime class names to exempt. - runtimeClasses: [] - # Array of namespaces to exempt. - namespaces: [] -``` -{{% /tab %}} -{{< /tabs >}} From a1be4f42d4f56607b07a4b363c91d02700d5cb66 Mon Sep 17 00:00:00 2001 From: Mauren Berti Date: Wed, 22 Feb 2023 10:23:29 -0500 Subject: [PATCH 013/215] Fix typo. --- .../enforce-standards-admission-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md b/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md index d3eb331c5d91c..ce2788a8dd977 100644 --- a/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md +++ b/content/pt-br/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md @@ -3,7 +3,7 @@ title: Aplicando os Padrões de Segurança do Pod Através da Configuração do content_type: task --- -O Kubernetes force um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +O Kubernetes fornece um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) embutido para garantir os [padrões de segurança do Pod](/docs/concepts/security/pod-security-standards). Você pode configurar esse controlador de admissão para definir padrões e [isenções](/docs/concepts/security/pod-security-admission/#exemptions) em todo From 1179ec8b11a8328cd12f77498d83c656b791172d Mon Sep 17 00:00:00 2001 From: Ana Carolina Rodrigues Date: Wed, 22 Feb 2023 13:53:38 -0300 Subject: [PATCH 014/215] Update content/pt-br/docs/issues-security/issues.md --- content/pt-br/docs/reference/issues-security/issues.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt-br/docs/reference/issues-security/issues.md b/content/pt-br/docs/reference/issues-security/issues.md index c1c8584739491..d0480ed558b3a 100644 --- a/content/pt-br/docs/reference/issues-security/issues.md +++ b/content/pt-br/docs/reference/issues-security/issues.md @@ -4,9 +4,9 @@ weight: 10 aliases: [/pt-br/cve/,/pt-br/cves/] --- -Para reportar um problema de segurança, siga [processo de divulgação de issues do Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability). +Para reportar um problema de segurança, siga [processo de divulgação de segurança do Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability). -O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando [ GitHub Issues ](https://github.com/kubernetes/kubernetes/issues/). +O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando [issues do GitHub](https://github.com/kubernetes/kubernetes/issues/). * Lista [oficial de CVEs conhecidos](/docs/reference/issues-security/official-cve-feed/) (vulnerabilidades de segurança) que foram anunciados pelo From 351c4789df25beeb21449cf247e9e770b9047ec7 Mon Sep 17 00:00:00 2001 From: Arhell Date: Thu, 23 Feb 2023 00:05:43 +0200 Subject: [PATCH 015/215] rename config.toml to hugo.toml --- config.toml => hugo.toml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename config.toml => hugo.toml (100%) diff --git a/config.toml b/hugo.toml similarity index 100% rename from config.toml rename to hugo.toml From 6b801158094a491924a36dcf493e2274b98f4779 Mon Sep 17 00:00:00 2001 From: Arhell Date: Fri, 24 Feb 2023 07:58:05 +0200 Subject: [PATCH 016/215] [hi] improvement: kubectl install on windows verify command --- content/hi/docs/tasks/tools/install-kubectl-windows.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/hi/docs/tasks/tools/install-kubectl-windows.md b/content/hi/docs/tasks/tools/install-kubectl-windows.md index fc7d1e1870ad0..5af06aaf32792 100644 --- a/content/hi/docs/tasks/tools/install-kubectl-windows.md +++ b/content/hi/docs/tasks/tools/install-kubectl-windows.md @@ -54,7 +54,7 @@ Windows पर kubectl संस्थापित करने के लिए - `True` या `False` परिणाम प्राप्त करने के लिए `-eq` ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए powershell का उपयोग करें: ```powershell - $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) + $(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256) ``` 1. अपने `PATH` में बाइनरी जोड़ें। From 2afb7d7d7e17c41d740d8fc9c6af552c3123cba0 Mon Sep 17 00:00:00 2001 From: Dipesh Rawat Date: Fri, 24 Feb 2023 16:23:15 +0000 Subject: [PATCH 017/215] Changed the occurrence of scratch to test --- .../configure-access-multiple-clusters.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 03dc6b4dc031f..ca7f6897d32c8 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -41,12 +41,12 @@ cluster's API server. ## Define clusters, users, and contexts -Suppose you have two clusters, one for development work and one for scratch work. +Suppose you have two clusters, one for development work and one for test work. In the `development` cluster, your frontend developers work in a namespace called `frontend`, -and your storage developers work in a namespace called `storage`. In your `scratch` cluster, +and your storage developers work in a namespace called `storage`. In your `test` cluster, developers work in the default namespace, or they create auxiliary namespaces as they see fit. Access to the development cluster requires authentication by certificate. Access -to the scratch cluster requires authentication by username and password. +to the test cluster requires authentication by username and password. Create a directory named `config-exercise`. In your `config-exercise` directory, create a file named `config-demo` with this content: @@ -60,7 +60,7 @@ clusters: - cluster: name: development - cluster: - name: scratch + name: test users: - name: developer @@ -72,7 +72,7 @@ contexts: - context: name: dev-storage - context: - name: exp-scratch + name: exp-test ``` A configuration file describes clusters, users, and contexts. Your `config-demo` file @@ -83,7 +83,7 @@ your configuration file: ```shell kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file -kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify +kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify ``` Add user details to your configuration file: @@ -108,7 +108,7 @@ Add context details to your configuration file: ```shell kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer -kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter +kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter ``` Open your `config-demo` file to see the added details. As an alternative to opening the @@ -130,7 +130,7 @@ clusters: - cluster: insecure-skip-tls-verify: true server: https://5.6.7.8 - name: scratch + name: test contexts: - context: cluster: development @@ -143,10 +143,10 @@ contexts: user: developer name: dev-storage - context: - cluster: scratch + cluster: test namespace: default user: experimenter - name: exp-scratch + name: exp-test current-context: "" kind: Config preferences: {} @@ -220,19 +220,19 @@ users: client-key: fake-key-file ``` -Now suppose you want to work for a while in the scratch cluster. +Now suppose you want to work for a while in the test cluster. -Change the current context to `exp-scratch`: +Change the current context to `exp-test`: ```shell -kubectl config --kubeconfig=config-demo use-context exp-scratch +kubectl config --kubeconfig=config-demo use-context exp-test ``` Now any `kubectl` command you give will apply to the default namespace of -the `scratch` cluster. And the command will use the credentials of the user -listed in the `exp-scratch` context. +the `test` cluster. And the command will use the credentials of the user +listed in the `exp-test` context. -View configuration associated with the new current context, `exp-scratch`. +View configuration associated with the new current context, `exp-test`. ```shell kubectl config --kubeconfig=config-demo view --minify @@ -338,10 +338,10 @@ contexts: user: developer name: dev-storage - context: - cluster: scratch + cluster: test namespace: default user: experimenter - name: exp-scratch + name: exp-test ``` For more information about how kubeconfig files are merged, see From 307c08071b420453edeabd612a9b3999cc7828da Mon Sep 17 00:00:00 2001 From: ziyi-xie Date: Mon, 27 Feb 2023 10:05:33 +0000 Subject: [PATCH 018/215] Update /content/ja/docs/concepts/workloads/controllers/daemonset.md --- .../workloads/controllers/daemonset.md | 85 ++++++++++++------- 1 file changed, 53 insertions(+), 32 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 42647228e6180..da2671ca776e3 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -33,12 +33,12 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 YAMLファイルに基づいてDaemonSetを作成します。 ``` -kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yal ``` ### 必須のフィールド -他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 +他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 DaemonSetオブジェクトの名前は、有効な [DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 @@ -49,17 +49,18 @@ DaemonSetオブジェクトの名前は、有効な `.spec.template`は`.spec`内での必須のフィールドの1つです。 -`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 -### Podセレクター +### Podセレクター -`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 +`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/ja/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 -Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 +ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。 +また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 `.spec.selector`は2つのフィールドからなるオブジェクトです。 @@ -77,17 +78,11 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ ## Daemon Podがどのようにスケジューリングされるか -### デフォルトスケジューラーによってスケジューリングされる場合 +DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。DaemonSetコントローラーは対象となる各Nodeに対してPodを作成し、ターゲットホストに一致するようにPodの`spec.affinity.nodeAffinity`フィールドを追加します。Podが作成されると、デフォルトのスケジューラーが慣例的に引き継ぎ、`.spec.nodeName`を設定することでPodをターゲットホストにバインドします。新しいNodeに適合できない場合、デフォルトスケジューラーは新しいPodの[優先度](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)に基づいて既存Podのいくつかを先取り（退避）させることがあります。 -{{< feature-state for_k8s_version="1.17" state="stable" >}} +ユーザーは、DaemonSetの`.spec.template.spec.schedulerName`フィールドを設定することにより、DaemonSetのPodsに対して異なるスケジューラーを指定することができます。 -DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。通常、Podが稼働するNodeはKubernetesスケジューラーによって選択されます。しかし、DaemonSetのPodは代わりにDaemonSetコントローラーによって作成され、スケジューリングされます。 -下記の問題について説明します: - - * 矛盾するPodのふるまい: スケジューリングされるのを待っている通常のPodは、作成されているが`Pending`状態となりますが、DaemonSetのPodは`Pending`状態で作成されません。これはユーザーにとって困惑するものです。 - * [Podプリエンプション(Pod preemption)](/docs/concepts/configuration/pod-priority-preemption/)はデフォルトスケジューラーによってハンドルされます。もしプリエンプションが有効な場合、そのDaemonSetコントローラーはPodの優先順位とプリエンプションを考慮することなくスケジューリングの判断を行います。 - -`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 +`.spec.template.spec.affinity.nodeAffinity`フィールド(指定された場合)で指定された元のNodeアフィニティは、DaemonSetコントローラーが対象Nodeを評価する際に考慮されますが、作成されたPod上では対象Nodeの名前と一致するNodeアフィニティに置き換わります。 ```yaml nodeAffinity: @@ -100,29 +95,41 @@ nodeAffinity: - target-host-name ``` -さらに、`node.kubernetes.io/unschedulable:NoSchedule`というtolarationがDaemonSetのPodに自動的に追加されます。デフォルトスケジューラーは、DaemonSetのPodのスケジューリングのときに、`unschedulable`なNodeを無視します。 -### TaintsとTolerations +### TaintとToleration + +DaemonSetコントローラーはDaemonSet Podに一連の{{< glossary_tooltip +text="Toleration" term_id="toleration" >}}を自動的に追加します: + +{{< table caption="Tolerations for DaemonSet pods" >}} + +| Toleration key | Effect | Details | +| --------------------------------------------------------------------------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | +| [`node.kubernetes.io/not-ready`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-not-ready) | `NoExecute` | 健康でないNodeや、Podを受け入れる準備ができていないNodeにDaemonSet Podをスケジュールできるように設定します。そのようなNode上で動作しているDaemonSet Podは退避されることがありません。 | +| [`node.kubernetes.io/unreachable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable) | `NoExecute` | Nodeコントローラーから到達できないNodeにDaemonSet Podをスケジュールできるように設定します。このようなNode上で動作しているDaemonSet Podは、退避されません。 | +| [`node.kubernetes.io/disk-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure) | `NoSchedule` | ディスク不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | メモリ不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 処理プレッシャー問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/unschedulable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | スケジューリング不可能なNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **ホストネットワークを要求するDaemonSet Podにのみ追加できます**、つまり`spec.hostNetwork: true`と設定されているPodです。このようなDaemonSet Podは、ネットワークが利用できないNodeにスケジュールできるように設定できます。| -DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 +{{< /table >}} -| Toleration Key | Effect | Version | Description | -| ---------------------------------------- | ---------- | ------- | ----------- | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。| -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | ホストネットワークを使うDaemonSetのPodはデフォルトスケジューラーによってネットワーク利用不可能な属性を許容(tolerate)します。 | +DaemonSetのPodテンプレートで定義すれば、DaemonSetのPodに独自のTolerationを追加することも可能です。 + +DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule`Tolerationを自動的に設定するため、Kubernetesは _スケジューリング不可能_ としてマークされているNodeでDaemonSet Podを実行することが可能です。 + +[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)のような重要なNodeレベル機能をDaemonSetで提供する場合、KubernetesがDaemonSet PodをNodeが準備完了になる前に配置することは有用です。 +例えば、その特別なTolerationがなければ、ネットワークプラグインがそこで実行されていないためにNodeが準備完了としてマークされず、同時にNodeがまだ準備完了でないためにそのNode上でネットワークプラグインが実行されていないというデッドロック状態に陥ってしまう可能性があるのです。 ## Daemon Podとのコミュニケーション DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。: -- **Push**: DaemonSet内のPodは他のサービスに対して更新情報を送信するように設定されます。 +- **Push**: DaemonSet内のPodは統計データベースなどの他のサービスに対して更新情報を送信するように設定されます。クライアントは持っていません。 - **NodeIPとKnown Port**: PodがNodeIPを介して疎通できるようにするため、DaemonSet内のPodは`hostPort`を使用できます。慣例により、クライアントはNodeIPのリストとポートを知っています。 - **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。 -- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。 +- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。(特定のNodeにアクセスする方法がありません。) ## DaemonSetの更新 @@ -130,7 +137,7 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ ユーザーはDaemonSetが作成したPodを修正可能です。しかし、Podは全てのフィールドの更新を許可していません。また、DaemonSetコントローラーは次のNode(同じ名前でも)が作成されたときにオリジナルのテンプレートを使ってPodを作成します。 -ユーザーはDaemonSetを削除可能です。`kubectl`コマンドで`--cascade=false`を指定するとDaemonSetのPodはNode上に残り続けます。その後、同じセレクターで新しいDaemonSetを作成すると、新しいDaemonSetは既存のPodを再利用します。PodでDaemonSetを置き換える必要がある場合は、`updateStrategy`に従ってそれらを置き換えます。 +ユーザーはDaemonSetを削除可能です。`kubectl`コマンドで`--cascade=orphan`を指定するとDaemonSetのPodはNode上に残り続けます。その後、同じセレクターで新しいDaemonSetを作成すると、新しいDaemonSetは既存のPodを再利用します。PodでDaemonSetを置き換える必要がある場合は、`updateStrategy`に従ってそれらを置き換えます。 ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。 @@ -142,13 +149,13 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd` - アプリケーションと同じ方法でデーモンの監視とログの管理ができる。 - デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。 -- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です(Dockerを介して直接起動する)。 +- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です。 ### ベアPod 特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。 -### 静的Pod Pods +### 静的Pod Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 @@ -157,5 +164,19 @@ Kubeletによって監視されているディレクトリに対してファイ DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 -Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 +DaemonSetがNodeレベルの機能を提供し、他のPodがその特定のNodeで正しく動作するようにする場合、Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 + +例えば、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)には、DaemonSetとして動作するコンポーネントが含まれていることがよくあります。DaemonSetコンポーネントは、それが動作しているNodeでクラスターネットワークが動作していることを確認します。 + + +## {{% heading "whatsnext" %}} +* [Pod](/ja/docs/concepts/workloads/pods/)について学ぶ。 + * Kubernetesの{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}コンポーネントを実行するのに便利な[静的Pod](#static-pods)について学ぶ。 +* DaemonSetの使用方法を確認する + * [DaemonSetでローリングアップデートを実施する](/docs/tasks/manage-daemon/update-daemon-set/) + * [DaemonSetでロールバックを実行する](/docs/tasks/manage-daemon/rollback-daemon-set/) + (例えば、ロールアウトが期待通りに動作しなかった場合)。 +* [Node上へのPodのスケジューリング](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)の仕組みを理解する +* よくDaemonSetとして実行される[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)と[アドオン](/ja/docs/concepts/cluster-administration/addons/)について学ぶ。 +* `DaemonSet`は、Kubernetes REST APIのトップレベルのリソースです。デーモンセットのAPIを理解するため{{< api-reference page="workload-resources/daemon-set-v1" >}}オブジェクトの定義を読む。 From 8a7476c1579b276ad28ff877f379cae4ad7218da Mon Sep 17 00:00:00 2001 From: lakshmi Date: Tue, 28 Feb 2023 12:51:20 +0530 Subject: [PATCH 019/215] corrected reference link for ComponentConfig. --- content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md index 7ce410607622a..9fc3f4702df88 100644 --- a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md +++ b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md @@ -33,7 +33,7 @@ General Availability means different things for different projects. For kubeadm, We now consider kubeadm to have achieved GA-level maturity in each of these important domains: * **Stable command-line UX** --- The kubeadm CLI conforms to [#5a GA rule of the Kubernetes Deprecation Policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli), which states that a command or flag that exists in a GA version must be kept for at least 12 months after deprecation. - * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/0014-20180707-componentconfig-api-types-to-staging.md) is used for configuring the [kubelet](/docs/reference/command-line-tools-reference/kubelet/). + * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/115-componentconfig) is used for configuring the [kubelet](/docs/reference/command-line-tools-reference/kubelet/). * **Configuration file schema** --- With the new **v1beta1** API version, you can now tune almost every part of the cluster declaratively and thus build a "GitOps" flow around kubeadm-built clusters. In future versions, we plan to graduate the API to version **v1** with minimal changes (and perhaps none). * **The "toolbox" interface of kubeadm** --- Also known as **phases**. If you don't want to perform all [`kubeadm init`](/docs/reference/setup-tools/kubeadm/kubeadm-init/) tasks, you can instead apply more fine-grained actions using the `kubeadm init phase` command (for example generating certificates or control plane [Static Pod](/docs/tasks/administer-cluster/static-pod/) manifests). * **Upgrades between minor versions** --- The [`kubeadm upgrade`](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) command is now fully GA. It handles control plane upgrades for you, which includes upgrades to [etcd](https://etcd.io), the [API Server](/docs/reference/using-api/api-overview/), the [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), and the [Scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). You can seamlessly upgrade your cluster between minor or patch versions (e.g. v1.12.2 -> v1.13.1 or v1.13.1 -> v1.13.3). From c6c09236c7b49ef8926204c83dffa6abe5cfc89c Mon Sep 17 00:00:00 2001 From: ziyi-xie Date: Wed, 1 Mar 2023 08:29:13 +0000 Subject: [PATCH 020/215] Update /content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: nasa9084 Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> Co-authored-by: atoato88 --- .../scheduling-eviction/assign-pod-node.md | 355 +++++++++--------- 1 file changed, 175 insertions(+), 180 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 7256b988f1b13..a8cf9e0129b23 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -7,212 +7,230 @@ weight: 20 -{{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 -これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 -スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 -SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 +{{< glossary_tooltip text="Pod" term_id="pod" >}}を特定の{{< glossary_tooltip text="Node" term_id="node" >}}で実行するように _制限_ したり、特定のNodeで実行することを _優先_ させたりといった制約をかけることができます。 +これを実現するためにはいくつかの方法がありますが、推奨されている方法は、すべて[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)を使用して選択を容易にすることです。 +多くの場合、このような制約を設定する必要はなく、{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}が自動的に妥当な配置を行います(例えば、Podを複数のNodeに分散させ、空きリソースが十分でないNodeにPodを配置しないようにすることができます)。 +しかし、例えばSSDが接続されているNodeにPodが配置されるようにしたり、多くの通信を行う2つの異なるサービスのPodを同じアベイラビリティーゾーンに配置したりする等、どのNodeに配置するかを制御したい状況もあります。 + +Kubernetesが特定のPodの配置場所を選択するために、以下の方法があります: - + * [nodeラベル](#built-in-node-labels)に対してマッチングを行う[nodeSelector](#nodeselector)フィールド + * [アフィニティとアンチアフィニティ](#affinity-and-anti-affinity) + * [nodeName](#nodename)フィールド + * [Podのトポロジー分散制約](#pod-topology-spread-constraints) -## nodeSelector +## Nodeラベル {#built-in-node-labels} -`nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。 -`nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。 -あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 -最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。 +他の多くのKubernetesオブジェクトと同様に、Nodeにも[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)があります。[手動でラベルを付ける](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/#ラベルをNodeに追加する)ことができます。 +また、Kubernetesはクラスター内のすべてのNodeに対し、いくつかの標準ラベルを付けます。Nodeラベルの一覧については[よく使われるラベル、アノテーションとtaint](/docs/reference/labels-annotations-taints/)を参照してください。 -以下に、`nodeSelector`の使用例を紹介します。 +{{}} +これらのラベルの値はクラウドプロバイダー固有のもので、信頼性を保証できません。 +例えば、`kubernetes.io/hostname`の値はある環境ではNode名と同じになり、他の環境では異なる値になることがあります。 +{{}} -### ステップ0: 前提条件 +### Nodeの分離/制限 -この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 +Nodeにラベルを追加することで、Podを特定のNodeまたはNodeグループ上でのスケジューリングの対象にすることができます。この機能を使用すると、特定のPodが一定の独立性、安全性、または規制といった属性を持ったNode上でのみ実行されるようにすることができます。 -### ステップ1: Nodeへのラベルの付与 +Node分離するのにラベルを使用する場合、{{}}が修正できないラベルキーを選択してください。 +これにより、侵害されたNodeが自身でそれらのラベルを設定することで、スケジューラーがそのNodeにワークロードをスケジュールしてしまうのを防ぐことができます。 -`kubectl get nodes`で、クラスターのノードの名前を取得してください。 -そして、ラベルを付与するNodeを選び、`kubectl label nodes =`で選択したNodeにラベルを付与します。 -例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 +[`NodeRestriction`アドミッションプラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)は、kubeletが`node-restriction.kubernetes.io/`というプレフィックスを持つラベルを設定または変更するのを防ぎます。 -`kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。 -また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。 +ラベルプレフィックスをNode分離に利用するには: -### ステップ2: PodへのnodeSelectorフィールドの追加 +1. [Node認可](/docs/reference/access-authn-authz/node/)を使用していることと、`NodeRestriction` アドミッションプラグインが _有効_ になっていることを確認します。 +2. `node-restriction.kubernetes.io/`プレフィックスを持つラベルをNodeに追加し、 [nodeSelector](#nodeselector)でそれらのラベルを使用します。 + 例えば、`example.com.node-restriction.kubernetes.io/fips=true`や`example.com.node-restriction.kubernetes.io/pci-dss=true`などです。 -該当のPodのconfigファイルに、nodeSelectorのセクションを追加します: -例として以下のconfigファイルを扱います: +## nodeSelector {#nodeselector} -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: nginx - labels: - env: test -spec: - containers: - - name: nginx - image: nginx -``` +`nodeSelector`は、Node選択制約の中で最もシンプルな推奨形式です。 +Podのspec(仕様)に`nodeSelector`フィールドを追加することで、ターゲットNodeが持つべき[Nodeラベル](#built-in-node-labels)を指定できます。 +Kubernetesは指定された各ラベルを持つNodeにのみ、Podをスケジューリングします。 -nodeSelectorを以下のように追加します: +詳しい情報については[PodをNodeに割り当てる](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)を参照してください。 -{{< codenew file="pods/pod-nginx.yaml" >}} +## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} -`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 -`kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 +`nodeSelector`はPodを特定のラベルが付与されたNodeに制限する最も簡単な方法です。 +アフィニティとアンチアフィニティでは、定義できる制約の種類が拡張されています。 +アフィニティとアンチアフィニティのメリットは以下の通りです。 -## 補足: ビルトインNodeラベル {#built-in-node-labels} +* アフィニティとアンチアフィニティで使われる言語は、より表現力が豊かです。`nodeSelector`は指定されたラベルを全て持つNodeを選択するだけです。アフィニティとアンチアフィニティは選択ロジックをより細かく制御することができます。 +* ルールが*柔軟*であったり*優先*での指定ができたりするため、一致するNodeが見つからない場合でも、スケジューラーはPodをスケジュールします。 +* Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルを使ってPodを制約することができます。これにより、Node上にどのPodを共存させるかのルールを定義することができます。 -明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 -これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。 +アフィニティ機能は、2種類のアフィニティで構成されています: -{{< note >}} -これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 -例えば、`kubernetes.io/hostname`の値はNodeの名前と同じである環境もあれば、異なる環境もあります。 -{{< /note >}} +* *Nodeアフィニティ*は`nodeSelector`フィールドと同様に機能しますが、より表現力が豊かで、より柔軟にルールを指定することができます。 +* *Pod間アフィニティとアンチアフィニティ*は、他のPodのラベルを元に、Podを制約することができます。 +### Nodeアフィニティ {#node-affinity} -## Nodeの隔離や制限 -Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。 -これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。 -この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 -これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 +Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 -`NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 -Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 +Nodeアフィニティには2種類あります: -1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。 -2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 -例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 + * `requiredDuringSchedulingIgnoredDuringExecution`: + スケジューラーは、ルールが満たされない限り、Podをスケジュールすることができません。これは`nodeSelector`と同じように機能しますが、より表現力豊かな構文になっています。 + * `preferredDuringSchedulingIgnoredDuringExecution`: + スケジューラーは、対応するルールを満たすNodeを探そうとします。 一致するNodeが見つからなくても、スケジューラーはPodをスケジュールします。 -## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} +{{}} +上記の2種類にある`IgnoredDuringExecution`は、KubernetesがPodをスケジュールした後にNodeラベルが変更されても、Podは実行し続けることを意味します。 +{{}} -`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 -アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 -拡張機能は以下の通りです。 +Podのspec(仕様)にある`.spec.affinity.nodeAffinity`フィールドを使用して、Nodeアフィニティを指定することができます。 -1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 -2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 -3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 +例えば、次のようなPodのspec(仕様)を考えてみましょう: -アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 -Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 +{{< codenew file="pods/pod-with-node-affinity.yaml" >}} -### Nodeアフィニティ +この例では、以下のルールが適用されます: -Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 + * Nodeには`topology.kubernetes.io/zone`をキーとするラベルが*必要*で、そのラベルの値は`antarctica-east1`または`antarctica-west1`のいずれかでなければなりません。 + * Nodeにはキー名が`another-node-label-key`で、値が`another-node-label-value`のラベルを持つことが*望ましい*です。 -現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 -前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 -"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも -PodはそのNodeで稼働し続けるということです。 -将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 +`operator`フィールドを使用して、Kubernetesがルールを解釈する際に使用できる論理演算子を指定することができます。`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`が使用できます。 -それぞれの使用例として、 -`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 -`preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" -といった方法が挙げられます。 +`NotIn`と`DoesNotExist`を使って、Nodeのアンチアフィニティ動作を定義することができます。また、[NodeのTaint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用して、特定のNodeからPodをはじくこともできます。 -Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 +{{}} +`nodeSelector`と`nodeAffinity`の両方を指定した場合、*両方の*条件を満たさないとPodはNodeにスケジュールされません。 -Nodeアフィニティを使用したPodの例を以下に示します: +`nodeAffinity`タイプに関連付けられた`nodeSelectorTerms`内に、複数の条件を指定した場合、Podは指定した条件のいずれかを満たしたNodeへスケジュールされます(条件はORされます)。 -{{< codenew file="pods/pod-with-node-affinity.yaml" >}} +`nodeSelectorTerms`内の条件に関連付けられた1つの`matchExpressions`フィールド内に、複数の条件を指定した場合、Podは全ての条件を満たしたNodeへスケジュールされます(条件はANDされます)。 +{{}} + +詳細については[Nodeアフィニティを利用してPodをNodeに割り当てる](/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)を参照してください。 + +#### Nodeアフィニティの重み + +`preferredDuringSchedulingIgnoredDuringExecution`アフィニティタイプの各インスタンスに、1から100の範囲の`weight`を指定できます。 +Podの他のスケジューリング要件をすべて満たすNodeを見つけると、スケジューラーはそのNodeが満たすすべての優先ルールを繰り返し実行し、対応する式の`weight`値を合計に加算します。 + +最終的な合計は、そのNodeの他の優先度関数のスコアに加算されます。合計スコアが最も高いNodeが、スケジューラーがPodのスケジューリングを決定する際に優先されます。 + +例えば、次のようなPodのspec(仕様)を考えてみましょう: -このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 -加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 +{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}} -この例ではオペレーター`In`が使われています。 -Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 -`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)に使用します。 +`preferredDuringSchedulingIgnoredDuringExecution`ルールにマッチするNodeとして、一つは`label-1:key-1`ラベル、もう一つは`label-2:key-2`ラベルの2つの候補がある場合、スケジューラーは各Nodeの`weight`を考慮し、その重みとNodeの他のスコアを加え、最終スコアが最も高いNodeにPodをスケジューリングします。 -`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 +{{}} +この例でKubernetesにPodを正常にスケジュールさせるには、`kubernetes.io/os=linux`ラベルを持つ既存のNodeが必要です。 +{{}} -`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 +#### スケジューリングプロファイルごとのNodeアフィニティ {#node-affinity-per-scheduling-profile} -`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。 +{{< feature-state for_k8s_version="v1.20" state="beta" >}} -PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 -言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 +複数の[スケジューリングプロファイル](/ja/docs/reference/scheduling/config/#multiple-profiles)を設定する場合、プロファイルにNodeアフィニティを関連付けることができます。これは、プロファイルが特定のNode群にのみ適用される場合に便利です。[スケジューラーの設定](/ja/docs/reference/scheduling/config/)にある[`NodeAffinity`プラグイン](/ja/docs/reference/scheduling/config/#scheduling-plugins)の`args`フィールドに`addedAffinity`を追加すると実現できます。例えば: -`preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 -全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 -このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration + +profiles: + - schedulerName: default-scheduler + - schedulerName: foo-scheduler + pluginConfig: + - name: NodeAffinity + args: + addedAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: scheduler-profile + operator: In + values: + - foo +``` + +`addedAffinity`は、Podの仕様(spec)で指定されたNodeアフィニティに加え、`.spec.schedulerName`を`foo-scheduler`に設定したすべてのPodに適用されます。つまり、Podにマッチするためには、Nodeは`addedAffinity`とPodの`.spec.NodeAffinity`を満たす必要があるのです。 + +`addedAffinity`はエンドユーザーには見えないので、その動作はエンドユーザーにとって予期しないものになる可能性があります。スケジューラープロファイル名と明確な相関関係のあるNodeラベルを使用すべきです。 + +{{< note >}} +[DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。 +{{< /note >}} -### Pod間アフィニティとアンチアフィニティ +### Pod間のアフィニティとアンチアフィニティ -Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 -このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 -Yはnamespaceのリストで指定したLabelSelectorで表されます。 -Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 -概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 -これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 -先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 +Pod間のアフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNode上で稼働している**Pod**のラベルに従って、PodがどのNodeにスケジュールされるかを制限できます。 +XはNodeや、ラック、クラウドプロバイダーのゾーンやリージョン等を表すトポロジードメインで、YはKubernetesが満たそうとするルールである場合、Pod間のアフィニティとアンチアフィニティのルールは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで実行すべき(アンチアフィニティの場合はすべきではない)"という形式です。 + +これらのルール(Y)は、オプションの関連する名前空間のリストを持つ[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)で表現されます。PodはKubernetesの名前空間オブジェクトであるため、Podラベルも暗黙的に名前空間を持ちます。Kubernetesが指定された名前空間でラベルを探すため、Podラベルのラベルセレクターは、名前空間を指定する必要があります。 + +トポロジードメイン(X)は`topologyKey`で表現され、システムがドメインを示すために使用するNodeラベルのキーになります。具体例は[よく知られたラベル、アノテーションとTaint](/docs/reference/labels-annotations-taints/)を参照してください。 {{< note >}} -Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 -そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 +Pod間アフィニティとアンチアフィニティはかなりの処理量を必要とするため、大規模クラスターでのスケジューリングが大幅に遅くなる可能性があります +そのため、数百台以上のNodeから成るクラスターでの使用は推奨されません。 {{< /note >}} {{< note >}} -Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。 -言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 -それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 +Podのアンチアフィニティは、Nodeに必ず一貫性の持つラベルが付与されている必要があります。 +言い換えると、クラスターの全てのNodeが、`topologyKey`に合致する適切なラベルが必要になります。 +一部、または全部のNodeに`topologyKey`ラベルが指定されていない場合、意図しない挙動に繋がる可能性があります。 {{< /note >}} -Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 -前述のNodeアフィニティのセクションを参照してください。 -`requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 -また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 +#### Pod間のアフィニティとアンチアフィニティの種類 + +[Nodeアフィニティ](#node-affinity)と同様に、Podアフィニティとアンチアフィニティにも下記の2種類があります: + + * `requiredDuringSchedulingIgnoredDuringExecution` + * `preferredDuringSchedulingIgnoredDuringExecution` + +例えば、`requiredDuringSchedulingIgnoredDuringExecution`アフィニティを使用して、2つのサービスのPodはお互いのやり取りが多いため、同じクラウドプロバイダーゾーンに併置するようにスケジューラーに指示することができます。 +同様に、`preferredDuringSchedulingIgnoredDuringExecution`アンチアフィニティを使用して、あるサービスのPodを複数のクラウドプロバイダーゾーンに分散させることができます。 + +Pod間アフィニティを使用するには、Pod仕様(spec)の`affinity.podAffinity`フィールドで指定します。Pod間アンチアフィニティを使用するには、Pod仕様(spec)の`affinity.podAntiAffinity`フィールドで指定します。 -Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。 +#### Podアフィニティ使用例 {#an-example-of-a-pod-that-uses-pod-affinity} -#### Podアフィニティを使用したPodの例 +次のようなPod仕様(spec)を考えてみましょう: {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 -この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 -Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`topology.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 -Node Nがキー`topology.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 -Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています -(`topologyKey`が`topology.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 -PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 +この例では、PodアフィニティルールとPodアンチアフィニティルールを1つずつ定義しています。 +Podアフィニティルールは"ハード"な`requiredDuringSchedulingIgnoredDuringExecution`を使用し、アンチアフィニティルールは"ソフト"な`preferredDuringSchedulingIgnoredDuringExecution`を使用しています。 -PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 +アフィニティルールは、スケジューラーがNodeにPodをスケジュールできるのは、そのNodeが、`security=S1`ラベルを持つ1つ以上の既存のPodと同じゾーンにある場合のみであることを示しています。より正確には、現在Podラベル`security=S1`を持つPodが1つ以上あるNodeが、そのゾーン内に少なくとも1つ存在する限り、スケジューラーは`topology.kubernetes.io/zone=V`ラベルを持つNodeにPodを配置しなければなりません。 -原則として、`topologyKey`には任意のラベルとキーが使用できます。 -しかし、パフォーマンスやセキュリティの観点から、以下の制約があります: +アンチアフィニティルールは、`security=S2`ラベルを持つ1つ以上のPodと同じゾーンにあるNodeには、スケジューラーがPodをスケジュールしないようにすることを示しています。より正確には、Podラベル`Security=S2`を持つPodが稼働している他のNodeが、同じゾーン内に存在する場合、スケジューラーは`topology.kubernetes.io/zone=R`ラベルを持つNodeにはPodを配置しないようにしなければなりません。 -1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。 -2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 -トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。 -3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。 -4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができます。 +Podアフィニティとアンチアフィニティの使用例についてもっと知りたい方は[デザイン案](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)を参照してください。 -`labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 -省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 +Podアフィニティとアンチアフィニティの`operator`フィールドで使用できるのは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 -`requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 +原則として、`topologyKey`には任意のラベルキーが指定できますが、パフォーマンスやセキュリティの観点から、以下の例外があります: +* Podアフィニティとアンチアフィニティでは、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`内のどちらも、`topologyKey`フィールドが空であることは許可されていません。 +* Podアンチアフィニティルールの`requiredDuringSchedulingIgnoredDuringExecution`では、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が`topologyKey`を`kubernetes.io/hostname`に制限しています。アドミッションコントローラーを修正または無効化すると、トポロジーのカスタマイズができるようになります。 -#### 実際的なユースケース +`labelSelector`と`topologyKey`に加え、`labelSelector`と`topologyKey`と同じレベルの`namespaces`フィールドを使用して、`labelSelector`が合致すべき名前空間のリストを任意に指定することができます。省略または空の場合、`namespaces`がデフォルトで、アフィニティとアンチアフィニティが定義されたPodの名前空間に設定されます。 -Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。 -Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 +#### 名前空間セレクター +{{< feature-state for_k8s_version="v1.24" state="stable" >}} +`namespaceSelector`を使用し、ラベルで名前空間の集合に対して検索することによって、名前空間を選択することができます。 +アフィニティ項は`namespaceSelector`と`namespaces`フィールドによって選択された名前空間に適用されます。 +要注意なのは、空の`namespaceSelector`({})はすべての名前空間にマッチし、nullまたは空の`namespaces`リストとnullの`namespaceSelector`は、ルールが定義されているPodの名前空間にマッチします。 -##### 常に同じNodeで稼働させる場合 +#### 実践的なユースケース -３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 -このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。 +Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。これらのルールにより、ワークロードのセットが同じ定義されたトポロジーに併置されるように設定できます。たとえば、2つの関連するPodを同じNodeに配置することが好ましい場合です。 -ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。 -Deploymentには、1つのNodeにレプリカを共存させないために`PodAntiAffinity`を付与しています。 +例えば、3つのNodeで構成されるクラスターを想像してください。クラスターを使用してウェブアプリケーションを実行し、さらにインメモリキャッシュ（Redisなど）を使用します。この例では、ウェブアプリケーションとメモリキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。 +以下のRedisキャッシュのDeploymentの例では、各レプリカはラベル`app=store`が付与されています。`podAntiAffinity`ルールは、`app=store`ラベルを持つ複数のレプリカを単一Nodeに配置しないよう、スケジューラーに指示します。これにより、各キャッシュが別々のNodeに作成されます。 ```yaml apiVersion: apps/v1 @@ -244,10 +262,7 @@ spec: image: redis:3.2-alpine ``` -ウェブサーバーのDeploymentを記載した以下のyamlファイルには、`podAntiAffinity` と`podAffinity`が設定されています。 -全てのレプリカが`app=store`のラベルが付与されたPodと同じゾーンで稼働するよう、スケジューラーに設定されます。 -また、それぞれのウェブサーバーは1つのノードで稼働されないことも保証されます。 - +次の Web サーバーのDeployment例では、`app=web-store`ラベルが付与されたレプリカを作成します。Podアフィニティルールは、各レプリカを、`app=store`ラベルが付与されたPodを持つNodeに配置するようスケジューラーに指示します。Podアンチアフィニティルールは、1つのNodeに複数の`app=web-store`サーバーを配置しないようにスケジューラーに指示します。 ```yaml apiVersion: apps/v1 @@ -288,49 +303,29 @@ spec: image: nginx:1.16-alpine ``` -上記2つのDeploymentが生成されると、3つのノードは以下のようになります。 +上記2つのDeploymentが生成されると、以下のようなクラスター構成になり、各Webサーバーはキャッシュと同位置に、3つの別々のNodeに配置されます。 | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | *webserver-1* | *webserver-2* | *webserver-3* | | *cache-1* | *cache-2* | *cache-3* | -このように、3つの`web-server`は期待通り自動的にキャッシュと共存しています。 - -``` -kubectl get pods -o wide -``` -出力は以下のようになります: -``` -NAME READY STATUS RESTARTS AGE IP NODE -redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3 -redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1 -redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2 -web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1 -web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3 -web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 -``` - -##### 同じNodeに共存させない場合 - -上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。 -同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 +全体的な効果として、各キャッシュインスタンスは、同じNode上で実行している単一のクライアントによってアクセスされる可能性が高いです。この方法は、スキュー(負荷の偏り)とレイテンシーの両方を最小化することを目的としています。 +Podアンチアフィニティを使用する理由は他にもあります。 +この例と同様の方法で、アンチアフィニティを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeperチュートリアル](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。 ## nodeName -`nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。 -`nodeName`はPodSpecのフィールドです。 -ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。 -そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。 +`nodeName`はアフィニティや`nodeSelector`よりも直接的なNode選択形式になります。`nodeName`はPod仕様(spec)のフィールドです。`nodeName`フィールドが空でない場合、スケジューラーはPodを考慮せずに、指定されたNodeにあるkubeletはそのNodeにPodを配置しようとします。`nodeName`を使用すると、`nodeSelector`やアフィニティおよびアンチアフィニティルールを使用するよりも優先されます。 - `nodeName`を使用することによる制約は以下の通りです: + `nodeName`を使ってNodeを選択する場合の制約は以下の通りです: -- その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。 -- その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由は例えばOutOfmemoryやOutOfcpuになります。 -- クラウド上のNodeの名前は予期できず、変更される可能性があります。 +- 指定されたNodeが存在しない場合、Podは実行されず、場合によっては自動的に削除されることがあります。 +- 指定されたNodeがPodを収容するためのリソースを持っていない場合、Podの起動は失敗し、OutOfmemoryやOutOfcpuなどの理由が表示されます。 +- クラウド環境におけるNode名は、常に予測可能で安定したものではありません。 -`nodeName`を指定したPodの設定ファイルの例を示します: +以下は、`nodeName`フィールドを使用したPod仕様(spec)の例になります: ```yaml apiVersion: v1 @@ -344,18 +339,18 @@ spec: nodeName: kube-01 ``` -上記のPodはkube-01という名前のNodeで稼働します。 - +上記のPodは`kube-01`というNodeでのみ実行されます。 +## Podトポロジー分散制約 {#pod-topology-spread-constraints} -## {{% heading "whatsnext" %}} - +_トポロジー分散制約_ を使って、リージョン、ゾーン、Nodeなどの障害ドメイン間、または定義したその他のトポロジードメイン間で、クラスター全体にどのように{{< glossary_tooltip text="Pod" term_id="Pod" >}}を分散させるかを制御することができます。これにより、パフォーマンス、予想される可用性、または全体的な使用率を向上させることができます。 -[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。 +詳しい仕組みについては、[トポロジー分散制約](/docs/concepts/scheduling-eviction/topology-spread-constraints/)を参照してください。 -[Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と -[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -のデザインドキュメントには、これらの機能の追加のバックグラウンドの情報が記載されています。 +## {{% heading "whatsnext" %}} -一度PodがNodeに割り当たると、kubeletはPodを起動してノード内のリソースを確保します。 -[トポロジーマネージャー](/docs/tasks/administer-cluster/topology-manager/)はNodeレベルのリソース割り当てを決定する際に関与します。 +* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)についてもっと読む。 +* [Nodeアフィニティ](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)と[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)のデザインドキュメントを読む。 +* [トポロジーマネージャー](/ja/docs/tasks/administer-cluster/topology-manager/)がNodeレベルリソースの割り当て決定に参加する方法について学ぶ。 +* [nodeSelector](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)の使用方法について学ぶ。 +* [アフィニティとアンチアフィニティ](/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)の使用方法について学ぶ。 From 9781390c523ab1a11e01a977f932daf8dce24fd3 Mon Sep 17 00:00:00 2001 From: ziyi-xie Date: Wed, 1 Mar 2023 09:06:03 +0000 Subject: [PATCH 021/215] add content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml file --- .../pods/pod-with-affinity-anti-affinity.yaml | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml diff --git a/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml new file mode 100644 index 0000000000000..f5f698d1f9b57 --- /dev/null +++ b/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -0,0 +1,33 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-affinity-anti-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/os + operator: In + values: + - linux + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: label-1 + operator: In + values: + - key-1 + - weight: 50 + preference: + matchExpressions: + - key: label-2 + operator: In + values: + - key-2 + containers: + - name: with-node-affinity + image: registry.k8s.io/pause:2.0 + \ No newline at end of file From dbd72395cd23148315f03a9f7934a052b665a1c0 Mon Sep 17 00:00:00 2001 From: Peter Arboleda Date: Wed, 1 Mar 2023 14:29:10 +0100 Subject: [PATCH 022/215] Update endpoint-slices.md --- content/en/docs/concepts/services-networking/endpoint-slices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 5d83300032771..30fbb4ae5bf1d 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -235,7 +235,7 @@ at different times. {{< note >}} Clients of the EndpointSlice API must iterate through all the existing EndpointSlices associated to a Service and build a complete list of unique network endpoints. It is -important to mention that endpoints may be duplicated in different EndointSlices. +important to mention that endpoints may be duplicated in different EndpointSlices. You can find a reference implementation for how to perform this endpoint aggregation and deduplication as part of the `EndpointSliceCache` code within `kube-proxy`. From dda415932020c49aede37201e3cbca7d235fcc12 Mon Sep 17 00:00:00 2001 From: hxysayhi <51870525+hxysayhi@users.noreply.github.com> Date: Thu, 2 Mar 2023 09:39:30 +0800 Subject: [PATCH 023/215] Update topology-spread-constraints.md Fixed translation errors. --- .../concepts/scheduling-eviction/topology-spread-constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md index 37a2fd0b20937..afb4aefbc3985 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -958,7 +958,7 @@ section of the enhancement proposal about Pod topology spread constraints. - 该调度器不会预先知道集群拥有的所有可用区和其他拓扑域。 拓扑域由集群中存在的节点确定。在自动扩缩的集群中，如果一个节点池（或节点组）的节点数量缩减为零， 而用户正期望其扩容时，可能会导致调度出现问题。 - 因为在这种情况下，调度器不会考虑这些拓扑域，因为其中至少有一个节点。 + 因为在这种情况下，调度器不会考虑这些拓扑域，直至这些拓扑域中至少包含有一个节点。 你可以通过使用感知 Pod 拓扑分布约束并感知整个拓扑域集的集群自动扩缩工具来解决此问题。 From ee3ba4e39504c40d860bfccd3afb0eb6a62e19ad Mon Sep 17 00:00:00 2001 From: s-kawamura-w664 Date: Thu, 2 Mar 2023 08:35:18 +0000 Subject: [PATCH 024/215] [ja] update some roles and links --- content/ja/docs/contribute/review/for-approvers.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/contribute/review/for-approvers.md b/content/ja/docs/contribute/review/for-approvers.md index ea17bba99ecf1..822396fbf67ea 100644 --- a/content/ja/docs/contribute/review/for-approvers.md +++ b/content/ja/docs/contribute/review/for-approvers.md @@ -61,13 +61,13 @@ Prowコマンド | Roleの制限 | 説明 :------------|:------------------|:----------- `/lgtm` | Organizationメンバー | PRのレビューが完了し、変更に納得したことを知らせる。 `/approve` | Approver | PRをマージすることを承認する。 -`/assign` | ReviewerまたはApprover | PRのレビューまたは承認するひとを割り当てる。 -`/close` | ReviewerまたはApprover | issueまたはPRをcloseする。 +`/assign` | 誰でも | PRのレビューまたは承認するひとを割り当てる。 +`/close` | Organizationメンバー | issueまたはPRをcloseする。 `/hold` | 誰でも | `do-not-merge/hold`ラベルを追加して、自動的にマージできないPRであることを示す。 `/hold cancel` | 誰でも | `do-not-merge/hold`ラベルを削除する。 {{< /table >}} -PRで利用できるすべてのコマンド一覧を確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help)を参照してください。 +PRで利用できるすべてのコマンドを確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help?repo=kubernetes%2Fwebsite)を参照してください。 ## issueのトリアージとカテゴリー分類 @@ -141,7 +141,7 @@ SIG Docsでは、対処方法をドキュメントに書いても良いくらい ### Blogに関するissue -[Kubernetes Blog](https://kubernetes.io/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 +[Kubernetes Blog](/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 ### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports} From d6445848fc32d9cb832f020a9fd5845f4d346ccf Mon Sep 17 00:00:00 2001 From: ClimberJ <98227175+ClimberJ@users.noreply.github.com> Date: Thu, 2 Mar 2023 12:14:13 +0100 Subject: [PATCH 025/215] Removed duplicate word --- content/en/docs/concepts/workloads/pods/pod-qos.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-qos.md b/content/en/docs/concepts/workloads/pods/pod-qos.md index b2035c520f404..9b0b10dedadbe 100644 --- a/content/en/docs/concepts/workloads/pods/pod-qos.md +++ b/content/en/docs/concepts/workloads/pods/pod-qos.md @@ -71,7 +71,7 @@ A Pod is given a QoS class of `Burstable` if: Pods in the `BestEffort` QoS class can use node resources that aren't specifically assigned to Pods in other QoS classes. For example, if you have a node with 16 CPU cores available to the -kubelet, and you assign assign 4 CPU cores to a `Guaranteed` Pod, then a Pod in the `BestEffort` +kubelet, and you assign 4 CPU cores to a `Guaranteed` Pod, then a Pod in the `BestEffort` QoS class can try to use any amount of the remaining 12 CPU cores. The kubelet prefers to evict `BestEffort` Pods if the node comes under resource pressure. From c90fd0f340ae93e91d1a319e4b3770655319c013 Mon Sep 17 00:00:00 2001 From: s-kawamura-w664 Date: Fri, 3 Mar 2023 09:08:17 +0000 Subject: [PATCH 026/215] [ja] Update page weights under content/ja/docs/reference. --- .../ja/docs/reference/command-line-tools-reference/_index.md | 2 +- content/ja/docs/reference/kubectl/_index.md | 2 +- content/ja/docs/reference/kubectl/cheatsheet.md | 1 + content/ja/docs/reference/kubectl/conventions.md | 1 + content/ja/docs/reference/kubectl/jsonpath.md | 2 +- content/ja/docs/reference/scheduling/_index.md | 2 +- content/ja/docs/reference/scheduling/policies.md | 1 + content/ja/docs/reference/setup-tools/_index.md | 2 +- content/ja/docs/reference/using-api/_index.md | 2 +- 9 files changed, 9 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/_index.md b/content/ja/docs/reference/command-line-tools-reference/_index.md index 89d64ce646db7..2e4806da13d42 100644 --- a/content/ja/docs/reference/command-line-tools-reference/_index.md +++ b/content/ja/docs/reference/command-line-tools-reference/_index.md @@ -1,5 +1,5 @@ --- title: コマンドラインツールのリファレンス -weight: 60 +weight: 120 toc-hide: true --- diff --git a/content/ja/docs/reference/kubectl/_index.md b/content/ja/docs/reference/kubectl/_index.md index 7b6c2d720b12a..6738659218c18 100644 --- a/content/ja/docs/reference/kubectl/_index.md +++ b/content/ja/docs/reference/kubectl/_index.md @@ -1,5 +1,5 @@ --- title: "kubectl CLI" -weight: 60 +weight: 110 --- diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 7b2d782882cfd..31a56103ccf92 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -1,6 +1,7 @@ --- title: kubectlチートシート content_type: concept +weight: 10 # highlight it card: name: reference weight: 30 diff --git a/content/ja/docs/reference/kubectl/conventions.md b/content/ja/docs/reference/kubectl/conventions.md index 338c97152adac..a1ee10d6e1e87 100644 --- a/content/ja/docs/reference/kubectl/conventions.md +++ b/content/ja/docs/reference/kubectl/conventions.md @@ -1,6 +1,7 @@ --- title: kubectlの使用規則 content_type: concept +weight: 60 --- diff --git a/content/ja/docs/reference/kubectl/jsonpath.md b/content/ja/docs/reference/kubectl/jsonpath.md index 9b9caca4bb3b0..fc382444ddc11 100644 --- a/content/ja/docs/reference/kubectl/jsonpath.md +++ b/content/ja/docs/reference/kubectl/jsonpath.md @@ -1,7 +1,7 @@ --- title: JSONPathのサポート content_type: concept -weight: 25 +weight: 40 --- diff --git a/content/ja/docs/reference/scheduling/_index.md b/content/ja/docs/reference/scheduling/_index.md index 316b774081953..6a44b52845201 100644 --- a/content/ja/docs/reference/scheduling/_index.md +++ b/content/ja/docs/reference/scheduling/_index.md @@ -1,5 +1,5 @@ --- title: Scheduling -weight: 70 +weight: 140 toc-hide: true --- diff --git a/content/ja/docs/reference/scheduling/policies.md b/content/ja/docs/reference/scheduling/policies.md index dd236d3c3db20..620adbc1a2603 100644 --- a/content/ja/docs/reference/scheduling/policies.md +++ b/content/ja/docs/reference/scheduling/policies.md @@ -3,6 +3,7 @@ title: スケジューリングポリシー content_type: concept sitemap: priority: 0.2 # スケジューリングポリシーは廃止されました。 +weight: 30 --- diff --git a/content/ja/docs/reference/setup-tools/_index.md b/content/ja/docs/reference/setup-tools/_index.md index 8341a25236359..0ccc1ece2f0e3 100644 --- a/content/ja/docs/reference/setup-tools/_index.md +++ b/content/ja/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- title: セットアップツールのリファレンス -weight: 50 +weight: 100 --- diff --git a/content/ja/docs/reference/using-api/_index.md b/content/ja/docs/reference/using-api/_index.md index 543b78b2c84a9..5df9a0391835d 100644 --- a/content/ja/docs/reference/using-api/_index.md +++ b/content/ja/docs/reference/using-api/_index.md @@ -1,7 +1,7 @@ --- title: API概要 content_type: concept -weight: 10 +weight: 20 no_list: true card: name: reference From 4a885ceca8839245502881a9834b5c05253b1b79 Mon Sep 17 00:00:00 2001 From: Shogo Hida Date: Sun, 19 Feb 2023 11:54:43 +0900 Subject: [PATCH 027/215] Fix paths Signed-off-by: Shogo Hida --- .../cluster-administration-overview.md | 6 +----- .../concepts/cluster-administration/manage-deployment.md | 5 ++--- .../concepts/configuration/manage-resources-containers.md | 2 +- .../reference/command-line-tools-reference/feature-gates.md | 4 ++-- .../ja/docs/tasks/debug/debug-cluster/local-debugging.md | 2 +- .../guestbook-logs-metrics-with-elk.md | 4 ++-- 6 files changed, 9 insertions(+), 14 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 9f27d7779df53..11c7285609b80 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -49,7 +49,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [Kubernetesクラスターでのsysctlの使用](/docs/concepts/cluster-administration/sysctl-cluster/)では、管理者向けにカーネルパラメーターを設定するため`sysctl`コマンドラインツールの使用方法について解説します。 -* [クラスターの監査](/docs/tasks/debug-application-cluster/audit/)では、Kubernetesの監査ログの扱い方について解説します。 +* [クラスターの監査](/ja/docs/tasks/debug/debug-cluster/audit/)では、Kubernetesの監査ログの扱い方について解説します。 ### kubeletをセキュアにする * [マスターとノードのコミュニケーション](/ja/docs/concepts/architecture/master-node-communication/) @@ -61,7 +61,3 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [DNSのインテグレーション](/ja/docs/concepts/services-networking/dns-pod-service/)では、DNS名をKubernetes Serviceに直接名前解決する方法を解説します。 * [クラスターアクティビィのロギングと監視](/docs/concepts/cluster-administration/logging/)では、Kubernetesにおけるロギングがどのように行われ、どう実装されているかについて解説します。 - - - - diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md index 084ff304b5c6a..35def1de1269e 100644 --- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md @@ -1,6 +1,6 @@ --- reviewers: -- +- title: リソースの管理 content_type: concept weight: 40 @@ -449,6 +449,5 @@ kubectl edit deployment/my-nginx ## {{% heading "whatsnext" %}} -- [アプリケーションの調査とデバッグのための`kubectl`の使用方法](/docs/tasks/debug-application-cluster/debug-application-introspection/)について学んでください。 +- [アプリケーションの調査とデバッグのための`kubectl`の使用方法](/ja/docs/tasks/debug/debug-application/debug-running-pod/)について学んでください。 - [設定のベストプラクティスとTIPS](/ja/docs/concepts/configuration/overview/)を参照してください。 - diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 62b01aa0dfe88..7004d7348dc8e 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -170,7 +170,7 @@ Dockerを使用する場合: Podのリソース使用量は、Podのステータスの一部として報告されます。 -オプションの[監視ツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)がクラスターにおいて利用可能な場合、Podのリソース使用量は[メトリクスAPI](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)から直接、もしくは監視ツールから取得できます。 +オプションの[監視ツール](/ja/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)がクラスターにおいて利用可能な場合、Podのリソース使用量は[メトリクスAPI](/ja/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#the-metrics-api)から直接、もしくは監視ツールから取得できます。 ## ローカルのエフェメラルストレージ {#local-ephemeral-storage} diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 76ee414f7bbb8..a014c7c608593 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -346,7 +346,7 @@ GAになってからさらなる変更を加えることは現実的ではない 各フィーチャーゲートは特定の機能を有効/無効にするように設計されています。 - `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。 -- `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。 +- `AdvancedAuditing`: [高度な監査機能](/ja/docs/tasks/debug/debug-cluster/audit/#advanced-audit)を有効にします。 - `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を有効にします。 - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。 @@ -387,7 +387,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。 -- `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。 +- `DynamicAuditing`: [動的監査](/docs/tasks/debug/debug-cluster/audit/#dynamic-backend)を有効にします。 - `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。 - `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。 diff --git a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md index 3272582fb367c..a0ef6f361115b 100644 --- a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md @@ -5,7 +5,7 @@ content_type: task -Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[get a shell on a running container](/docs/task/debug-application-cluster/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。 +Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[get a shell on a running container](/ja/docs/task/debug/debug-application/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。 `telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。 `telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。 diff --git a/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index 2e771a13b40c0..4eac56f950514 100644 --- a/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -456,7 +456,7 @@ DeploymentとServiceを削除すると、実行中のすべてのPodも削除さ ## {{% heading "whatsnext" %}} -* [リソースを監視するためのツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)について学ぶ。 +* [リソースを監視するためのツール](/ja/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)について学ぶ。 * [ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)についてもっと読む。 * [アプリケーションのイントロスペクションとデバッグ](/ja/docs/tasks/debug/debug-application/)についてもっと読む。 -* [アプリケーションのトラブルシューティング](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)についてもっと読む。 +* [アプリケーションのトラブルシューティング](/ja/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)についてもっと読む。 From fceca934ffbd6d3b508762fa36d1437e9a962b6f Mon Sep 17 00:00:00 2001 From: Shogo Hida Date: Mon, 20 Feb 2023 18:25:22 +0900 Subject: [PATCH 028/215] Fix troubleshooting Signed-off-by: Shogo Hida --- .../windows/intro-windows-in-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 2fa71ad2fc77b..ea9e947f6ae99 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -365,7 +365,7 @@ Windowsでは、PodSecurityContextフィールドはどれも機能しません ## ヘルプとトラブルシューティングを学ぶ {#troubleshooting} -Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、この[セクション](/docs/tasks/debug-application-cluster/troubleshooting/)から始める必要があります。このセクションには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 +Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、[トラブルシューティング](/ja/docs/tasks/debug/)ページから始める必要があります。このページには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 1. start.ps1が正常に完了したことをどのように確認できますか？ From 580a3a9eaf6e4a6656f5f97c6acfb72cd1543add Mon Sep 17 00:00:00 2001 From: Shogo Hida Date: Mon, 20 Feb 2023 18:28:53 +0900 Subject: [PATCH 029/215] Fix translation Signed-off-by: Shogo Hida --- .../windows/intro-windows-in-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index ea9e947f6ae99..aa30f5ceaa0b4 100644 --- a/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -365,7 +365,7 @@ Windowsでは、PodSecurityContextフィールドはどれも機能しません ## ヘルプとトラブルシューティングを学ぶ {#troubleshooting} -Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、[トラブルシューティング](/ja/docs/tasks/debug/)ページから始める必要があります。このページには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 +Kubernetesクラスターのトラブルシューティングの主なヘルプソースは、[トラブルシューティング](/ja/docs/tasks/debug/)ページから始める必要があります。このセクションには、いくつか追加的な、Windows固有のトラブルシューティングヘルプが含まれています。ログは、Kubernetesにおけるトラブルシューティング問題の重要な要素です。他のコントリビューターからトラブルシューティングの支援を求めるときは、必ずそれらを含めてください。SIG-Windows[ログ収集に関するコントリビュートガイド](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)の指示に従ってください。 1. start.ps1が正常に完了したことをどのように確認できますか？ From 1ae0421446e15e0ff69ef9cab91fd951624f84fa Mon Sep 17 00:00:00 2001 From: Shogo Hida Date: Sun, 26 Feb 2023 18:28:01 +0900 Subject: [PATCH 030/215] Fix path and add translation --- content/ja/docs/tasks/debug/debug-cluster/local-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md index a0ef6f361115b..8fe2c4a5f4999 100644 --- a/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/ja/docs/tasks/debug/debug-cluster/local-debugging.md @@ -5,7 +5,7 @@ content_type: task -Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[get a shell on a running container](/ja/docs/task/debug/debug-application/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。 +Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[実行中のコンテナへのシェルを取得](/ja/docs/tasks/debug/debug-application/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。 `telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。 `telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。 From b3f8293850911fefb2bc614899e7bc0025f15e4e Mon Sep 17 00:00:00 2001 From: Madhumita Kundo Date: Sun, 26 Feb 2023 12:20:18 +0000 Subject: [PATCH 031/215] [en] Update outdated update-readme-doc --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cbc8617dff809..7aa81971cf126 100644 --- a/README.md +++ b/README.md @@ -70,7 +70,7 @@ This will start the local Hugo server on port 1313. Open up your browser to . +The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, also known as OpenAPI specification, using . To update the reference pages for a new Kubernetes release follow these steps: From 76694cd68c8b4414bba59cca63f5d03574c940f7 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Tue, 28 Feb 2023 12:02:18 +0800 Subject: [PATCH 032/215] [zh-cn]sync blog 2022-09-07-iptables-chains.md Signed-off-by: xin.li --- .../blog/_posts/2022-09-07-iptables-chains.md | 343 ++++++++++++++++++ 1 file changed, 343 insertions(+) create mode 100644 content/zh-cn/blog/_posts/2022-09-07-iptables-chains.md diff --git a/content/zh-cn/blog/_posts/2022-09-07-iptables-chains.md b/content/zh-cn/blog/_posts/2022-09-07-iptables-chains.md new file mode 100644 index 0000000000000..2f6da8a69f043 --- /dev/null +++ b/content/zh-cn/blog/_posts/2022-09-07-iptables-chains.md @@ -0,0 +1,343 @@ +--- +layout: blog +title: "Kubernetes 的 iptables 链不是 API" +date: 2022-09-07 +slug: iptables-chains-not-api +--- + + + + +**作者：** Dan Winship (Red Hat) + +**译者：** Xin Li (DaoCloud) + + +一些 Kubernetes 组件（例如 kubelet 和 kube-proxy）在执行操作时，会创建特定的 iptables 链和规则。 +这些链从未被计划使其成为任何 Kubernetes API/ABI 保证的一部分， +但一些外部组件仍然使用其中的一些链（特别是使用 `KUBE-MARK-MASQ` 将数据包标记为需要伪装）。 + + +作为 v1.25 版本的一部分，SIG Network 明确声明： +Kubernetes 创建的 iptables 链仅供 Kubernetes 内部使用（有一个例外）， +第三方组件不应假定 Kubernetes 会创建任何特定的 iptables 链， +或者这些链将包含任何特定的规则（即使它们确实存在）。 + + +然后，在未来的版本中，作为 [KEP-3178] 的一部分，我们将开始逐步淘汰 Kubernetes +本身不再需要的某些链。Kubernetes 自身之外且使用了 `KUBE-MARK-MASQ`、`KUBE-MARK-DROP` +或 Kubernetes 所生成的其它 iptables 链的组件应当开始迁移。 + +[KEP-3178]: https://github.com/kubernetes/enhancements/issues/3178 + + +## 背景 {#background} + +除了各种为 Service 创建的 iptables 链之外，kube-proxy 还创建了某些通用 iptables 链， +用作服务代理的一部分。 过去，kubelet 还使用 iptables +来实现一些功能（例如为 Pod 设置 `hostPort` 映射），因此它也冗余地创建了一些重复的链。 + + +然而，随着 1.24 版本 Kubernetes 中 [dockershim 的移除]， +kubelet 现在不再为某种目的使用任何 iptables 规则； +过去使用 iptables 来完成的事情现在总是由容器运行时或网络插件负责， +现在 kubelet 没有理由创建任何 iptables 规则。 + +同时，虽然 iptables 仍然是 Linux 上默认的 kube-proxy 后端， +但它不会永远是默认选项，因为相关的命令行工具和内核 API 基本上已被弃用， +并且不再得到改进。（RHEL 9 [记录警告] 如果你使用 iptables API，即使是通过 `iptables-nft`。） + + +尽管在 Kubernetes 1.25，iptables kube-proxy 仍然很流行， +并且 kubelet 继续创建它过去创建的 iptables 规则（尽管不再**使用**它们）， +第三方软件不能假设核心 Kubernetes 组件将来会继续创建这些规则。 + +[移除 dockershim]: https://kubernetes.io/zh-cn/blog/2022/02/17/dockershim-faq/ +[记录警告]: https://access.redhat.com/solutions/6739041 + + +## 即将发生的变化 + +从现在开始的几个版本中，kubelet 将不再在 `nat` 表中创建以下 iptables 链： + + - `KUBE-MARK-DROP` + - `KUBE-MARK-MASQ` + - `KUBE-POSTROUTING` + +此外，`filter` 表中的 `KUBE-FIREWALL` 链将不再具有当前与 +`KUBE-MARK-DROP` 关联的功能（并且它最终可能会完全消失）。 + + +此更改将通过 `IPTablesOwnershipCleanup` 特性门控逐步实施。 +你可以手动在 Kubernetes 1.25 中开启此特性进行测试。 +目前的计划是将其在 Kubernetes 1.27 中默认启用， +尽管这可能会延迟到以后的版本。（不会在 Kubernetes 1.27 版本之前调整。） + + +## 如果你使用 Kubernetes 的 iptables 链怎么办 + +（尽管下面的讨论侧重于仍然基于 iptables 的短期修复， +但你可能也应该开始考虑最终迁移到 nftables 或其他 API。） + + +### 如果你使用 `KUBE-MARK-MASQ` 链... {#use-case-kube-mark-drop} + +如果你正在使用 `KUBE-MARK-MASQ` 链来伪装数据包， +你有两个选择：（1）重写你的规则以直接使用 `-j MASQUERADE`， +（2）创建你自己的替代链，完成“为伪装而设标记”的任务。 + + +kube-proxy 使用 `KUBE-MARK-MASQ` 的原因是因为在很多情况下它需要在数据包上同时调用 +`-j DNAT` 和 `-j MASQUERADE`，但不可能同时在 iptables 中调用这两种方法； +`DNAT` 必须从 `PREROUTING`（或 `OUTPUT`）链中调用（因为它可能会改变数据包将被路由到的位置）而 +`MASQUERADE` 必须从 `POSTROUTING` 中调用（因为它伪装的源 IP 地址取决于最终的路由）。 + + +理论上，kube-proxy 可以有一组规则来匹配 `PREROUTING`/`OUTPUT` +中的数据包并调用 `-j DNAT`，然后有第二组规则来匹配 `POSTROUTING` +中的相同数据包并调用 `-j MASQUERADE`。 +但是，为了提高效率，kube-proxy 只匹配了一次，在 `PREROUTING`/`OUTPUT` 期间调用 `-j DNAT`， +然后调用 `-j KUBE-MARK-MASQ` 在内核数据包标记属性上设置一个比特，作为对自身的提醒。 +然后，在 `POSTROUTING` 期间，通过一条规则来匹配所有先前标记的数据包，并对它们调用 `-j MASQUERADE`。 + + +如果你有**很多**规则需要像 kube-proxy 一样对同一个数据包同时执行 DNAT 和伪装操作， +那么你可能需要类似的安排。但在许多情况下，使用 `KUBE-MARK-MASQ` 的组件之所以这样做， +只是因为它们复制了 kube-proxy 的行为，而不理解 kube-proxy 为何这样做。 +许多这些组件可以很容易地重写为仅使用单独的 DNAT 和伪装规则。 +（在没有发生 DNAT 的情况下，使用 `KUBE-MARK-MASQ` 的意义就更小了； +只需将你的规则从 `PREROUTING` 移至 `POSTROUTING` 并直接调用 `-j MASQUERADE`。） + + +### 如果你使用 `KUBE-MARK-DROP`... {#use-case-kube-mark-drop} + +`KUBE-MARK-DROP` 的基本原理与 `KUBE-MARK-MASQ` 类似： +kube-proxy 想要在 `nat` `KUBE-SERVICES` 链中做出丢包决定以及其他决定， +但你只能从 `filter` 表中调用 `-j DROP`。 + + +通常，删除对 `KUBE-MARK-DROP` 的依赖的方法与删除对 `KUBE-MARK-MASQ` 的依赖的方法相同。 +在 kube-proxy 的场景中，很容易将 `nat` 表中的 `KUBE-MARK-DROP` +的用法替换为直接调用 `filter` 表中的 `DROP`，因为 DNAT 规则和 DROP 规则之间没有复杂的交互关系， +因此 DROP 规则可以简单地从 `nat` 移动到 `filter`。 +更复杂的场景中，可能需要在 `nat` 和 `filter` 表中“重新匹配”相同的数据包。 + + +### 如果你使用 Kubelet 的 iptables 规则来确定 `iptables-legacy` 与 `iptables-nft`... {#use-case-iptables-mode} + +对于从容器内部操纵主机网络命名空间 iptables 规则的组件而言，需要一些方法来确定主机是使用旧的 +`iptables-legacy` 二进制文件还是新的 `iptables-nft` 二进制文件（与不同的内核 API 交互）下。 + + +[`iptables-wrappers`] 模块为此类组件提供了一种自动检测系统 iptables 模式的方法， +但在过去，它通过假设 kubelet 将在任何容器启动之前创建“一堆” iptables +规则来实现这一点，因此它可以通过查看哪种模式定义了更多规则来猜测主机文件系统中的 +iptables 二进制文件正在使用哪种模式。 + +在未来的版本中，kubelet 将不再创建许多 iptables 规则， +因此基于计算存在的规则数量的启发式方法可能会失败。 + + +然而，从 1.24 开始，kubelet 总是在它使用的任何 iptables 子系统的 +`mangle` 表中创建一个名为 `KUBE-IPTABLES-HINT` 的链。 +组件现在可以查找这个特定的链，以了解 kubelet（以及系统的其余部分）正在使用哪个 iptables 子系统。 + +（此外，从 Kubernetes 1.17 开始，kubelet 在 `mangle` 表中创建了一个名为 `KUBE-KUBELET-CANARY` 的链。 +虽然这条链在未来可能会消失，但它仍然会在旧版本中存在，因此在任何最新版本的 Kubernetes 中， +至少会包含 `KUBE-IPTABLES-HINT` 或 `KUBE-KUBELET-CANARY` 两条链的其中一个。） + + +`iptables-wrappers` 包[已经被更新]，以提供这个新的启发式逻辑， +所以如果你以前使用过它，你可以用它的更新版本重建你的容器镜像。 + +[`iptables-wrappers`]: https://github.com/kubernetes-sigs/iptables-wrappers/ +[已经更新]: https://github.com/kubernetes-sigs/iptables-wrappers/pull/3 + + +## 延伸阅读 + +[KEP-3178] 跟踪了清理 iptables 链所有权和弃用旧链的项目。 + +[KEP-3178]: https://github.com/kubernetes/enhancements/issues/3178 \ No newline at end of file From 0dba6571d5bc7c524db95524f684cea3b201855e Mon Sep 17 00:00:00 2001 From: Arhell Date: Sat, 4 Mar 2023 10:56:17 +0200 Subject: [PATCH 033/215] [es] Change shell to console for code snippet --- .../configure-pod-container/configure-volume-storage.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/es/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/es/docs/tasks/configure-pod-container/configure-volume-storage.md index c4f08f29690e8..f5f8b17d97a77 100644 --- a/content/es/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/es/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -41,7 +41,7 @@ En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tie La salida debería ser similar a: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s ``` @@ -69,7 +69,7 @@ En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tie La salida debería ser similar a: - ```shell + ```console USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash @@ -86,7 +86,7 @@ En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tie 1. En el terminal original, observa los cambios en el Pod de Redis. Eventualmente verás algo como lo siguiente: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s redis 0/1 Completed 0 6m From 1318d4085311fa31566f16623c799035323682b3 Mon Sep 17 00:00:00 2001 From: David Xia Date: Sat, 4 Mar 2023 07:12:56 -0500 Subject: [PATCH 034/215] fix docs: update user-namespaces.md for English usage Make it grammatically correct and more concise. --- content/en/docs/concepts/workloads/pods/user-namespaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/pods/user-namespaces.md b/content/en/docs/concepts/workloads/pods/user-namespaces.md index 4241104ad4b61..0217490aa875d 100644 --- a/content/en/docs/concepts/workloads/pods/user-namespaces.md +++ b/content/en/docs/concepts/workloads/pods/user-namespaces.md @@ -10,7 +10,7 @@ min-kubernetes-server-version: v1.25 {{< feature-state for_k8s_version="v1.25" state="alpha" >}} This page explains how user namespaces are used in Kubernetes pods. A user -namespace allows to isolate the user running inside the container from the one +namespace isolates the user running inside the container from the one in the host. A process running as root in a container can run as a different (non-root) user From 6ceae5e94320cdc4b7d53e180bd94a15f7bb280e Mon Sep 17 00:00:00 2001 From: marianogg9 Date: Sat, 4 Mar 2023 15:06:16 +0100 Subject: [PATCH 035/215] added [ES] translated finalizer glossary item + concept page --- .../working-with-objects/finalizers.md | 87 +++++++++++++++++++ .../es/docs/reference/glossary/finalizer.md | 36 ++++++++ 2 files changed, 123 insertions(+) create mode 100644 content/es/docs/concepts/overview/working-with-objects/finalizers.md create mode 100644 content/es/docs/reference/glossary/finalizer.md diff --git a/content/es/docs/concepts/overview/working-with-objects/finalizers.md b/content/es/docs/concepts/overview/working-with-objects/finalizers.md new file mode 100644 index 0000000000000..04404f1e70cac --- /dev/null +++ b/content/es/docs/concepts/overview/working-with-objects/finalizers.md @@ -0,0 +1,87 @@ +--- +title: Finalizadores +content_type: concept +weight: 80 +--- + + + +{{}} + +Puedes usar finalizadores para controlar {{}} +de los recursos alertando a los controladores para que ejecuten tareas de limpieza especificas antes de eliminar el recurso. + +Los finalizadores usualmente no especifican codigo a ejecutar, sino que son generalmente listas de parametros referidos a +un recurso especifico, similares a las anotaciones. Kubernetes especifica algunos finalizadores automaticamente, +pero podrías especificar tus propios. + +## Cómo funcionan los finalizadores + +Cuando creas un recurso utilizando un archivo de manifiesto, puedes especificar +finalizadores mediante el campo `metadata.finalizers`. Cuando intentas eliminar el +recurso, el servidor API que maneja el pedido de eliminación ve los valores en el +campo `finalizadores` y hace lo siguiente: + + * Modifica el objecto para agregar un campo `metadata.deletionTimestamp` con + el momento en que comenzaste la eliminación. + * Previene que el objeto sea eliminado hasta que su campo `metadata.finalizers` + este vacío. + * Retorna un codigo de estado `202` (HTTP "Aceptado") + +El controlador que meneja ese finalizador recibe la actualización del objecto +configurando el campo `metadata.deletionTimestamp`, indicando que la eliminación +del objeto ha sido solicitada. +El controlador luego intenta satisfacer los requerimientos de los finalizadores +especificados para ese recurso. Cada vez que una condición del finalizador es +satisfecha, el controlador remueve ese parametro del campo `finalizadores`. Cuando +el campo `finalizadores` esta vacío, un objeto con un campo `deletionTimestamp` +configurado es automaticamente borrado. Puedes tambien utilizar finalizadores para +prevenir el borrado de recursos no manejados. + +Un ejemplo usual de un finalizador es `kubernetes.io/pv-protection`, el cual +previene el borrado accidental de objetos `PersistentVolume`. Cuando un objeto +`PersistentVolume` está en uso por un Pod, Kubernetes agrega el finalizador +`pv-protection`. Si intentas elimiar el `PersistentVolume`, este pasa a un estado +`Terminating`, pero el controlador no puede eliminarlo ya que existe el finalizador. +Cuando el Pod deja de utilizar el `PersistentVolume`, Kubernetes borra el finalizador +`pv-protection` y el controlador borra el volumen. + +## Referencias de dueño, etiquetas y finalizadores (#dueños-etiquetas-finalizadores) + +Al igual que las {{}}, las +[referencias de dueño](/docs/concepts/overview/working-with-objects/owners-dependents/) +describen las relaciones entre objetos en Kubernetes, pero son utilizadas para un +propósito diferente. Cuando un +{{}} maneja objetos como +Pods, utiliza etiquetas para identificar cambios a grupos de objetos relacionados. +Por ejemplo, cuando un {{}} crea uno +o más Pods, el controlador del Job agrega etiquetas a esos pods para identificar cambios +a cualquier Pod en el cluster con la misma etiqueta. + +El controlador del Job tambien agrega *referencias de dueño* a esos Pods, referidas +al Job que creo a los Pods. Si borras el Job mientras estos Pods estan corriendo, +Kubernetes utiliza las referencias de dueño (no las etiquetas) para determinar +cuáles Pods en el cluster deberían ser borrados. + +Kubernetes también procesa finalizadores cuando identifica referencias de dueño en +un recurso que ha sido marcado para eliminación. + +En algunas situaciones, los finalizadores pueden bloquear el borrado de objetos +dependientes, causando que el objeto inicial a borrar permanezca más de lo +esperado sin ser completamente eliminado. En esas situaciones, deberías chequear +finalizadores y referencias de dueños en los objetos y sus dependencias para +intentar solucionarlo. + +{{}} +En casos donde los objetos queden bloqueados en un estado de eliminación, evita +borrarlos manualmente para que el proceso continue. Los finalizadores usualmente +son agregados a los recursos por una razón, por lo cual eliminarlos forzosamente +puede causar problemas en tu cluster. Borrados manuales sólo deberían ejecutados +cuando el propósito del finalizador es entendido y satisfecho de alguna otra manera (por +ejemplo, borrando manualmente un objeto dependiente). +{{}} + +## {{% heading "whatsnext" %}} + +* Lea [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/) + en el blog de Kubernetes. \ No newline at end of file diff --git a/content/es/docs/reference/glossary/finalizer.md b/content/es/docs/reference/glossary/finalizer.md new file mode 100644 index 0000000000000..765ab36a83ad0 --- /dev/null +++ b/content/es/docs/reference/glossary/finalizer.md @@ -0,0 +1,36 @@ +--- +title: Finalizador +id: finalizer +date: 2021-07-07 +full_link: /docs/concepts/overview/working-with-objects/finalizers/ +short_description: > + Un atributo de un namespace que dicta a Kubernetes a esperar hasta que condiciones + especificas son satisfechas antes que pueda borrar un objeto marcado para eliminacion. +aka: +tags: +- fundamental +- operation +--- +Los finalizadores son atributos de un namespace que dictan a Kubernetes a +esperar a que ciertas condiciones sean satisfechas antes que pueda borrar +definitivamente un objeto que ha sido marcado para eliminarse. +Los finalizadores alertan a los {{}} +para borrar recursos que poseian esos objetos eliminados. + + + +Cuando instruyes a Kubernetes a borrar un objeto que tiene finalizadores +especificados, la API de Kubernetes marca ese objeto para eliminacion +configurando el campo `metadata.deletionTimestamp`, y retorna un codigo de +estado `202` (HTTP "Aceptado"). +El objeto a borrar permanece en un estado +de terminacion mientras el plano de contol, u otros componentes, ejecutan +las acciones definidas en los finalizadores. +Luego de que esas acciones son completadas, el controlador borra los +finalizadores relevantes del objeto. Cuando el campo `metadata.finalizers` +esta vacio, Kubernetes considera el proceso de eliminacion completo y borra +el objeto. + +Puedes utilizar finalizadores para controlar {{}} +de recursos. Por ejemplo, puedes definir un finalizador para borrar recursos +relacionados o infraestructura antes que el controlador elimine el objeto. \ No newline at end of file From e342648b91f3bda1b7f35cd39feb8acca957d2ef Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Fri, 3 Mar 2023 15:26:02 +0800 Subject: [PATCH 036/215] Fix the description of Service External IPs to match the YAML example --- content/en/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index bb6b1d3750029..09690eb71ece4 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -1165,7 +1165,7 @@ will be routed to one of the Service endpoints. `externalIPs` are not managed by of the cluster administrator. In the Service spec, `externalIPs` can be specified along with any of the `ServiceTypes`. -In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`" (`externalIP:port`) +In the example below, "`my-service`" can be accessed by clients on "`198.51.100.32:80`" (`externalIP:port`) ```yaml apiVersion: v1 From f9ccb1412d298eef83d739c1b13ea3c98a696c32 Mon Sep 17 00:00:00 2001 From: s-kawamura-w664 Date: Mon, 6 Mar 2023 04:23:41 +0000 Subject: [PATCH 037/215] [ja] Update page weights under security, storage and workloads. --- content/ja/docs/concepts/security/_index.md | 2 +- content/ja/docs/concepts/security/controlling-access.md | 1 + content/ja/docs/concepts/security/overview.md | 2 +- content/ja/docs/concepts/storage/dynamic-provisioning.md | 2 +- content/ja/docs/concepts/storage/storage-capacity.md | 2 +- content/ja/docs/concepts/storage/storage-limits.md | 1 + content/ja/docs/concepts/storage/volume-pvc-datasource.md | 2 +- content/ja/docs/concepts/storage/volume-snapshot-classes.md | 2 +- content/ja/docs/concepts/workloads/_index.md | 2 +- 9 files changed, 9 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/concepts/security/_index.md b/content/ja/docs/concepts/security/_index.md index 0088a3ea95d7e..b0912322b0263 100644 --- a/content/ja/docs/concepts/security/_index.md +++ b/content/ja/docs/concepts/security/_index.md @@ -1,6 +1,6 @@ --- title: "セキュリティ" -weight: 81 +weight: 85 description: > クラウドネイティブなワークロードをセキュアに維持するための概念 --- diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index b9ec55417f5e6..576613895ee4c 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -1,6 +1,7 @@ --- title: Kubernetes APIへのアクセスコントロール content_type: concept +weight: 50 --- diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index c9d656a423268..ca4410b775196 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -2,7 +2,7 @@ reviewers: title: クラウドネイティブセキュリティの概要 content_type: concept -weight: 10 +weight: 1 --- diff --git a/content/ja/docs/concepts/storage/dynamic-provisioning.md b/content/ja/docs/concepts/storage/dynamic-provisioning.md index 94bee64ed101a..07206c09830c3 100644 --- a/content/ja/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ja/docs/concepts/storage/dynamic-provisioning.md @@ -2,7 +2,7 @@ reviewers: title: ボリュームの動的プロビジョニング(Dynamic Volume Provisioning) content_type: concept -weight: 40 +weight: 50 --- diff --git a/content/ja/docs/concepts/storage/storage-capacity.md b/content/ja/docs/concepts/storage/storage-capacity.md index cff887a125a81..1151706a4f9c7 100644 --- a/content/ja/docs/concepts/storage/storage-capacity.md +++ b/content/ja/docs/concepts/storage/storage-capacity.md @@ -1,7 +1,7 @@ --- title: ストレージ容量 content_type: concept -weight: 45 +weight: 80 --- diff --git a/content/ja/docs/concepts/storage/storage-limits.md b/content/ja/docs/concepts/storage/storage-limits.md index 4f38361f0848a..e3df1f3bc9732 100644 --- a/content/ja/docs/concepts/storage/storage-limits.md +++ b/content/ja/docs/concepts/storage/storage-limits.md @@ -1,6 +1,7 @@ --- title: ノード固有のボリューム制限 content_type: concept +weight: 90 --- diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index fc1b7ae4b9d7d..8e0a9f7c7b86b 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -1,7 +1,7 @@ --- title: CSI Volume Cloning content_type: concept -weight: 30 +weight: 70 --- diff --git a/content/ja/docs/concepts/storage/volume-snapshot-classes.md b/content/ja/docs/concepts/storage/volume-snapshot-classes.md index ca381652d22b7..5c4c999625873 100644 --- a/content/ja/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ja/docs/concepts/storage/volume-snapshot-classes.md @@ -2,7 +2,7 @@ reviewers: title: VolumeSnapshotClass content_type: concept -weight: 30 +weight: 61 # just after volume snapshots --- diff --git a/content/ja/docs/concepts/workloads/_index.md b/content/ja/docs/concepts/workloads/_index.md index ca846cd0e7e99..94631dc878d64 100644 --- a/content/ja/docs/concepts/workloads/_index.md +++ b/content/ja/docs/concepts/workloads/_index.md @@ -1,6 +1,6 @@ --- title: "ワークロード" -weight: 50 +weight: 55 description: > Kubernetesにおけるデプロイ可能な最小のオブジェクトであるPodと、高レベルな抽象化がPodの実行を助けることを理解します。 no_list: true From 18107b55ae31f1b5739bbb166144da06e1ce8eb4 Mon Sep 17 00:00:00 2001 From: zhuzhenghao Date: Mon, 6 Mar 2023 13:43:44 +0800 Subject: [PATCH 038/215] [zh] sync page ns-level-pss --- .../docs/tutorials/security/ns-level-pss.md | 108 +++++++++--------- 1 file changed, 52 insertions(+), 56 deletions(-) diff --git a/content/zh-cn/docs/tutorials/security/ns-level-pss.md b/content/zh-cn/docs/tutorials/security/ns-level-pss.md index faf20f35993bf..1f793a4e375b6 100644 --- a/content/zh-cn/docs/tutorials/security/ns-level-pss.md +++ b/content/zh-cn/docs/tutorials/security/ns-level-pss.md @@ -11,7 +11,9 @@ weight: 20 --> {{% alert title="Note" %}} - + 本教程仅适用于新集群。 {{% /alert %}} @@ -24,7 +26,7 @@ when pods are created. In this tutorial, you will enforce the `baseline` Pod Sec one namespace at a time. You can also apply Pod Security Standards to multiple namespaces at once at the cluster -level. For instructions, refer to +level. For instructions, refer to [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/). --> Pod 安全准入（PSA）在 v1.23 及更高版本默认启用， @@ -59,15 +61,17 @@ Install the following on your workstation: 2. 按照如下方式创建一个 `KinD` 集群： ```shell - kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 + kind create cluster --name psa-ns-level ``` - + 输出类似于： ``` Creating cluster "psa-ns-level" ... - ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Ensuring node image (kindest/node:v{{< skew currentVersion >}}.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ @@ -75,26 +79,30 @@ Install the following on your workstation: ✓ 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'. ``` @@ -111,7 +119,9 @@ Create a new namespace called `example`: kubectl create ns example ``` - + 输出类似于： ``` @@ -119,34 +129,35 @@ namespace/example created ``` -## 应用 Pod 安全标准 {#apply-pod-security-standards} +## 为该命名空间启用 Pod 安全标准检查 {#enable-pod-security-standards-checking-for-that-namespace} 1. 使用内置 Pod 安全准入所支持的标签在此名字空间上启用 Pod 安全标准。 在这一步中，我们将根据最新版本（默认值）对基线 Pod 安全标准发出警告。 ```shell kubectl label --overwrite ns example \ - pod-security.kubernetes.io/warn=baseline \ - pod-security.kubernetes.io/warn-version=latest + pod-security.kubernetes.io/warn=baseline \ + pod-security.kubernetes.io/warn-version=latest ``` -2. 可以使用标签在任何名字空间上启用多个 Pod 安全标准。 +1. 你可以使用标签在任何名字空间上配置多个 Pod 安全标准检查。 以下命令将强制（`enforce`） 执行基线（`baseline`）Pod 安全标准， 但根据最新版本（默认值）对受限（`restricted`）Pod 安全标准执行警告（`warn`）和审核（`audit`）。 - ``` + ```shell kubectl label --overwrite ns example \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/enforce-version=latest \ @@ -157,56 +168,39 @@ namespace/example created ``` ## 验证 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` 名字空间中： +1. 在 `example` 名字空间中创建一个基线 Pod： ```shell - kubectl apply -n example -f /tmp/pss/nginx-pod.yaml + kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml ``` - - - 输出类似于： + + Pod 确实启动正常；输出包括一条警告信息。例如： ``` - 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") + 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` 名字空间中： +1. 在 `default` 名字空间中创建一个基线 Pod： ```shell - kubectl apply -n default -f /tmp/pss/nginx-pod.yaml + kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml ``` - + 输出类似于： ``` @@ -214,10 +208,11 @@ namespace/example created ``` +Pod 安全标准实施和警告设置仅被应用到 `example` 名字空间。 以上 Pod 安全标准仅被应用到 `example` 名字空间。 你可以在没有警告的情况下在 `default` 名字空间中创建相同的 Pod。 @@ -246,6 +241,7 @@ kind delete cluster --name psa-ns-level 3. Apply `baseline` Pod Security Standard in `enforce` mode while applying `restricted` Pod Security Standard also in `warn` and `audit` mode. 4. Create a new pod with the following pod security standards applied + - [Pod Security Admission](/docs/concepts/security/pod-security-admission/) - [Pod Security Standards](/docs/concepts/security/pod-security-standards/) - [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/) From 02c313169af7dfb04013c84594cf9e077bd84bd7 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Mon, 6 Mar 2023 16:39:18 +0900 Subject: [PATCH 039/215] Update content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml Co-authored-by: atoato88 --- content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml index f5f698d1f9b57..ba21557f2d6a4 100644 --- a/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/ja/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -29,5 +29,4 @@ spec: - key-2 containers: - name: with-node-affinity - image: registry.k8s.io/pause:2.0 - \ No newline at end of file + image: registry.k8s.io/pause:2.0 \ No newline at end of file From 4813cb9484d02ac054730abe32c9fc3d65f3866e Mon Sep 17 00:00:00 2001 From: saliha Date: Fri, 24 Feb 2023 14:35:10 +0900 Subject: [PATCH 040/215] [jp]Japanese localization for main page --- content/ja/blog/_index.md | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 content/ja/blog/_index.md diff --git a/content/ja/blog/_index.md b/content/ja/blog/_index.md new file mode 100644 index 0000000000000..673c4aeef29ed --- /dev/null +++ b/content/ja/blog/_index.md @@ -0,0 +1,4 @@ +--- +linktitle: Kubernetesブログ +title: ドキュメント +--- From 0e57c72a23e4293140174cfeb3afc873e78777cc Mon Sep 17 00:00:00 2001 From: saliha Date: Fri, 24 Feb 2023 14:38:54 +0900 Subject: [PATCH 041/215] changed to blog[jp] --- content/ja/blog/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_index.md b/content/ja/blog/_index.md index 673c4aeef29ed..e66f28220ac76 100644 --- a/content/ja/blog/_index.md +++ b/content/ja/blog/_index.md @@ -1,4 +1,4 @@ --- linktitle: Kubernetesブログ -title: ドキュメント +title: ブログ --- From 2a8d459f079f8870be1f463b415eaf8eea15efd3 Mon Sep 17 00:00:00 2001 From: saliha Date: Fri, 24 Feb 2023 14:45:06 +0900 Subject: [PATCH 042/215] changing title to match with linktitle --- content/ja/blog/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_index.md b/content/ja/blog/_index.md index e66f28220ac76..113c7f5a6d502 100644 --- a/content/ja/blog/_index.md +++ b/content/ja/blog/_index.md @@ -1,4 +1,4 @@ --- linktitle: Kubernetesブログ -title: ブログ +title: Kubernetesブログ --- From ca59f533e514a74014c9a48a41c2c1d47ac17777 Mon Sep 17 00:00:00 2001 From: Saliha <49085460+Saliha067@users.noreply.github.com> Date: Fri, 3 Mar 2023 19:49:15 +0900 Subject: [PATCH 043/215] Update content/ja/blog/_index.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/blog/_index.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/content/ja/blog/_index.md b/content/ja/blog/_index.md index 113c7f5a6d502..f4f2c571cae07 100644 --- a/content/ja/blog/_index.md +++ b/content/ja/blog/_index.md @@ -1,4 +1,16 @@ --- -linktitle: Kubernetesブログ title: Kubernetesブログ +linkTitle: ブログ +menu: + main: + title: "ブログ" + weight: 40 + post: > +

Kubernetesやコンテナ全般に関する最新ニュースを読んで、技術的なハウツーをいち早く入手しましょう。

--- +{{< comment >}} + +ブログへの寄稿についての情報は、以下を参照してください +https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post + +{{< /comment >}} From 48c6be119ceb367dc1f6b4a25434323113d25a55 Mon Sep 17 00:00:00 2001 From: zhuzhenghao Date: Mon, 6 Mar 2023 12:57:40 +0800 Subject: [PATCH 044/215] [zh] sync page deployment --- .../workloads/controllers/deployment.md | 98 ++++++++++--------- .../workloads/controllers/replicaset.md | 5 +- 2 files changed, 54 insertions(+), 49 deletions(-) diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md index 8f64bfeb3a5fa..657fba81ddfbf 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md @@ -8,6 +8,8 @@ content_type: concept weight: 10 --- @@ -97,8 +99,8 @@ In this example: - `spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。 + `.spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。 在 `matchLabels` 映射中的每个 `{key,value}` 映射等效于 `matchExpressions` 中的一个元素， 即其 `key` 字段是 “key”，`operator` 为 “In”，`values` 数组仅包含 “value”。 在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。 @@ -158,9 +160,9 @@ Follow the steps given below to create the above Deployment: ``` 2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。 如果仍在创建 Deployment，则输出类似于： @@ -208,7 +210,7 @@ Follow the steps given below to create the above Deployment: ``` 4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于： @@ -255,7 +257,7 @@ Follow the steps given below to create the above Deployment: @@ -296,7 +298,7 @@ Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的 {{< /note >}} ### Pod-template-hash 标签 @@ -323,13 +325,13 @@ and in any existing Pods that the ReplicaSet might have. 可能拥有的任何现有 Pod 中。 ## 更新 Deployment {#updating-a-deployment} {{< note >}} 仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新， @@ -353,7 +355,7 @@ Follow the steps given below to update your Deployment: or use the following command: --> 或者使用下面的命令： - + ```shell kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 ``` @@ -492,7 +494,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. then deletes an old Pod, and creates another new one. It does not kill old Pods until a sufficient number of new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed. It makes sure that at least 3 Pods are available and that at max 4 Pods in total are available. In case of - a Deployment with 4 replicas, the number of Pods would be between 3 and 5. + a Deployment with 4 replicas, the number of Pods would be between 3 and 5. --> 例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod， 并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。 @@ -559,8 +561,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. (nginx-deployment-1564180365) and scaled it up to 1 and waited for it to come up. Then it scaled down the old ReplicaSet to 2 and scaled up the new ReplicaSet to 2 so that at least 3 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down the new and the old ReplicaSet, with the same rolling update strategy. - Finally, you'll have 3 available replicas - in the new ReplicaSet, and the old ReplicaSet is scaled down to 0. + Finally, you'll have 3 available replicas in the new ReplicaSet, and the old ReplicaSet is scaled down to 0. --> 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（`nginx-deployment-2035384211`） 并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet @@ -624,7 +625,7 @@ before changing course. @@ -665,7 +666,7 @@ removed label still exists in any existing Pods and ReplicaSets. ## 回滚 Deployment {#rolling-back-a-deployment} @@ -697,7 +698,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 `nginx:1.161` 而不是 `nginx:1.16.1`： ```shell - kubectl set image deployment/nginx-deployment nginx=nginx:1.161 + kubectl set image deployment/nginx-deployment nginx=nginx:1.161 ``` * 你可以看到旧的副本有两个（`nginx-deployment-1564180365` 和 `nginx-deployment-2035384211`）， 新的副本有 1 个（`nginx-deployment-3066724191`）： @@ -748,7 +749,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 --> 输出类似于： - ```shell + ``` NAME DESIRED CURRENT READY AGE nginx-deployment-1564180365 3 3 3 25s nginx-deployment-2035384211 0 0 0 36s @@ -769,7 +770,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 --> 输出类似于： - ```shell + ``` NAME READY STATUS RESTARTS AGE nginx-deployment-1564180365-70iae 1/1 Running 0 25s nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s @@ -828,7 +829,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message + FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 @@ -855,7 +856,7 @@ Follow the steps given below to check the rollout history: 按照如下步骤检查回滚历史： 1. 首先，检查 Deployment 修订历史： @@ -929,7 +930,7 @@ Follow the steps given below to rollback the Deployment from the current version 按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本（即版本 2）。 1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本： @@ -1229,7 +1230,7 @@ The output is similar to this: --> 输出类似于： -```shell +``` NAME DESIRED CURRENT READY AGE nginx-deployment-1989198191 7 7 0 7m nginx-deployment-618515232 11 11 11 7m @@ -1307,7 +1308,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess --> 输出类似于： - ```shell + ``` deployment.apps/nginx-deployment paused ``` @@ -1363,7 +1364,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess --> 输出类似于： - ```shell + ``` NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 2m ``` @@ -1388,7 +1389,8 @@ apply multiple fixes in between pausing and resuming without triggering unnecess 暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment 上线被暂停期间不会产生任何效果。 @@ -1573,7 +1575,7 @@ The output is similar to this: --> 输出类似于： -```shell +``` Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment "nginx-deployment" successfully rolled out ``` @@ -1584,7 +1586,7 @@ and the exit status from `kubectl rollout` is 0 (success): 从 `kubectl rollout` 命令获得的返回状态为 0（成功）： ```shell -$ echo $? +echo $? ``` ``` 0 @@ -1603,7 +1605,7 @@ due to some of the following factors: 造成此情况一些可能因素如下： @@ -1687,8 +1689,8 @@ Deployment 不执行任何操作。更高级别的编排器可以利用这一设 {{< note >}} 如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。 @@ -1831,7 +1833,7 @@ and the exit status from `kubectl rollout` is 1 (indicating an error): `kubectl rollout` 命令的退出状态为 1（表明发生了错误）： ```shell -$ echo $? +echo $? ``` ``` 1 @@ -1899,9 +1901,9 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o 这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment， @@ -2114,7 +2116,7 @@ at all times during the update is at least 70% of the desired Pods. 如果以上比较结果都相同，则随机选择。 -本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。 +本文列举控制面节点（确切地说是 {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}}）和 +Kubernetes {{< glossary_tooltip text="集群" term_id="cluster" length="all" >}}之间的通信路径。 目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固， 使得集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。 @@ -51,35 +55,38 @@ API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上 或[服务账户令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 -应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 +应该使用集群的公共根{{< glossary_tooltip text="证书" term_id="certificate" >}}开通节点， +这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 -想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。 +想要连接到 API 服务器的 {{< glossary_tooltip text="Pod" term_id="pod" >}} +可以使用服务账号安全地进行连接。 当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 `kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址， -用于（通过 kube-proxy）转发请求到 API 服务器的 HTTPS 末端。 +用于（通过 `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`）转发请求到 +API 服务器的 HTTPS 末端。 控制面组件也通过安全端口与集群的 API 服务器通信。 @@ -90,15 +97,16 @@ networks. ## Control plane to node There are two primary communication paths from the control plane (the API server) to the nodes. -The first is from the API server to the kubelet process which runs on each node in the cluster. +The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster. The second is from the API server to any node, pod, or service through the API server's _proxy_ functionality. --> ## 控制面到节点 {#control-plane-to-node} 从控制面（API 服务器）到节点有两种主要的通信路径。 -第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。 -第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。 +第一种是从 API 服务器到集群中每个节点上运行的 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 进程。 +第二种是从 API 服务器通过它的**代理**功能连接到任何节点、Pod 或者服务。 ### SSH 隧道 {#ssh-tunnels} -Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下， -API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器） +Kubernetes 支持使用 +[SSH 隧道](https://www.ssh.com/academy/ssh/tunneling)来保护从控制面到节点的通信路径。 +在这种配置下，API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器） 并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 这一隧道保证通信不会被暴露到集群节点所运行的网络之外。 @@ -219,3 +228,22 @@ Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 请浏览 [Konnectivity 服务任务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/) 在你的集群中配置 Konnectivity 服务。 +## {{% heading "whatsnext" %}} + + +* 阅读 [Kubernetes 控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components) +* 进一步了解 [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors) +* 进一步了解如何[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/) +* 进一步了解 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) +* [设置 Konnectivity 服务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/) +* [使用端口转发来访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* 学习如何[检查 Pod 的日志](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs) + 以及如何[使用 kubectl 端口转发](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod) From fb3b32507191c57396f864eb7ec433ec0a934d46 Mon Sep 17 00:00:00 2001 From: Shogo Hida Date: Tue, 28 Feb 2023 19:08:44 +0900 Subject: [PATCH 046/215] Delete DynamicAuditing Signed-off-by: Shogo Hida --- .../docs/reference/command-line-tools-reference/feature-gates.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index a014c7c608593..5667cbee61b8b 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -387,7 +387,6 @@ GAになってからさらなる変更を加えることは現実的ではない - `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 - `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。 - `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。 -- `DynamicAuditing`: [動的監査](/docs/tasks/debug/debug-cluster/audit/#dynamic-backend)を有効にします。 - `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。 - `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。 - `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/ja/docs/concepts/storage/dynamic-provisioning/)を有効にします。 From 5038eba0ac5205b61974f5e0cbefb85a3f462d98 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 6 Mar 2023 17:58:58 +0800 Subject: [PATCH 047/215] [zh] sync configure-persistent-volume-storage.md --- .../configure-persistent-volume-storage.md | 36 +++++++++---------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 57c4f13a30b21..d2fc135403649 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -1,13 +1,12 @@ --- title: 配置 Pod 以使用 PersistentVolume 作为存储 content_type: task -weight: 60 +weight: 90 --- - @@ -19,11 +18,11 @@ for storage. Here is a summary of the process: 1. You, as cluster administrator, create a PersistentVolume backed by physical -storage. You do not associate the volume with any Pod. + storage. You do not associate the volume with any Pod. 1. You, now taking the role of a developer / cluster user, create a -PersistentVolumeClaim that is automatically bound to a suitable -PersistentVolume. + PersistentVolumeClaim that is automatically bound to a suitable + PersistentVolume. 1. You create a Pod that uses the above PersistentVolumeClaim for storage. --> @@ -43,15 +42,14 @@ PersistentVolume. - * 你需要一个包含单个节点的 Kubernetes 集群，并且必须配置 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 命令行工具以便与集群交互。 如果还没有单节点集群，可以使用 @@ -101,11 +99,11 @@ In the `/mnt/data` directory, create an `index.html` file: sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html" ``` +{{< note >}} -{{< note >}} 如果你的节点使用某工具而不是 `sudo` 来完成超级用户访问，你可以将上述命令中的 `sudo` 替换为该工具的名称。 {{< /note >}} @@ -374,7 +372,7 @@ use storage from a PersistentVolumeClaim. ## 清理 {#clean-up} @@ -395,11 +393,11 @@ In the shell on your Node, remove the file and directory that you created: 如果你还没有连接到集群中节点的 Shell，可以按之前所做操作，打开一个新的 Shell。 在节点的 Shell 上，删除你所创建的目录和文件： + - ```shell # 这里假定你使用 "sudo" 来以超级用户的角色执行命令 sudo rm /mnt/data/index.html @@ -426,8 +424,8 @@ You can perform 2 volume mounts on your nginx container: --> 你可以在 nginx 容器上执行两个卷挂载: -`/usr/share/nginx/html` 用于静态网站 -`/etc/nginx/nginx.conf` 作为默认配置 +- `/usr/share/nginx/html` 用于静态网站 +- `/etc/nginx/nginx.conf` 作为默认配置 @@ -472,11 +470,11 @@ each container. 应用的方法与 Pod 的安全上下文中指定的 GID 相同。 每个 GID，无论是来自 PersistentVolume 注解还是来自 Pod 规约，都会被应用于每个容器中运行的第一个进程。 +{{< note >}} -{{< note >}} 当 Pod 使用 PersistentVolume 时，与 PersistentVolume 关联的 GID 不会在 Pod 资源本身的对象上出现。 {{< /note >}} @@ -493,7 +491,7 @@ PersistentVolume are not present on the Pod resource itself. -### 参考 +### 参考 {#reference} * [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) From 3ea1d6790a2ddcbd420310cc0649e7ac26892d86 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 09:04:30 +0900 Subject: [PATCH 048/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index a8cf9e0129b23..d548e5e836e44 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -228,7 +228,7 @@ Podアフィニティとアンチアフィニティの`operator`フィールド Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。これらのルールにより、ワークロードのセットが同じ定義されたトポロジーに併置されるように設定できます。たとえば、2つの関連するPodを同じNodeに配置することが好ましい場合です。 -例えば、3つのNodeで構成されるクラスターを想像してください。クラスターを使用してウェブアプリケーションを実行し、さらにインメモリキャッシュ（Redisなど）を使用します。この例では、ウェブアプリケーションとメモリキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。 +例えば、3つのNodeで構成されるクラスターを想像してください。そのクラスターを使用してウェブアプリケーションを実行し、さらにインメモリーキャッシュ(Redisなど)を使用します。この例では、ウェブアプリケーションとメモリーキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。 以下のRedisキャッシュのDeploymentの例では、各レプリカはラベル`app=store`が付与されています。`podAntiAffinity`ルールは、`app=store`ラベルを持つ複数のレプリカを単一Nodeに配置しないよう、スケジューラーに指示します。これにより、各キャッシュが別々のNodeに作成されます。 From 3db17caaa305b7b0f0f20a59a83206b5f073e83a Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 09:04:43 +0900 Subject: [PATCH 049/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index d548e5e836e44..534356dc89d53 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -303,7 +303,7 @@ spec: image: nginx:1.16-alpine ``` -上記2つのDeploymentが生成されると、以下のようなクラスター構成になり、各Webサーバーはキャッシュと同位置に、3つの別々のNodeに配置されます。 +上記2つのDeploymentが生成されると、以下のようなクラスター構成になり、各ウェブサーバーはキャッシュと同位置に、3つの別々のNodeに配置されます。 | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| From e761735da67f5185eaae7fceac9e4ff1a8d92f21 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 09:05:12 +0900 Subject: [PATCH 050/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 534356dc89d53..c1d848d928ed0 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -351,6 +351,6 @@ _トポロジー分散制約_ を使って、リージョン、ゾーン、Node * [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)についてもっと読む。 * [Nodeアフィニティ](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)と[Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)のデザインドキュメントを読む。 -* [トポロジーマネージャー](/ja/docs/tasks/administer-cluster/topology-manager/)がNodeレベルリソースの割り当て決定に参加する方法について学ぶ。 +* [トポロジーマネージャー](/ja/docs/tasks/administer-cluster/topology-manager/)がNodeレベルのリソース割り当ての決定にどのように関与しているかについて学ぶ。 * [nodeSelector](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)の使用方法について学ぶ。 * [アフィニティとアンチアフィニティ](/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)の使用方法について学ぶ。 From fc6c72fab683c648d6f7b06fd15918fda1fe03da Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 09:05:42 +0900 Subject: [PATCH 051/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index c1d848d928ed0..a213ba723b487 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -262,7 +262,7 @@ spec: image: redis:3.2-alpine ``` -次の Web サーバーのDeployment例では、`app=web-store`ラベルが付与されたレプリカを作成します。Podアフィニティルールは、各レプリカを、`app=store`ラベルが付与されたPodを持つNodeに配置するようスケジューラーに指示します。Podアンチアフィニティルールは、1つのNodeに複数の`app=web-store`サーバーを配置しないようにスケジューラーに指示します。 +次のウェブサーバーのDeployment例では、`app=web-store`ラベルが付与されたレプリカを作成します。Podアフィニティルールは、各レプリカを、`app=store`ラベルが付与されたPodを持つNodeに配置するようスケジューラーに指示します。Podアンチアフィニティルールは、1つのNodeに複数の`app=web-store`サーバーを配置しないようにスケジューラーに指示します。 ```yaml apiVersion: apps/v1 From 7824b8d5e08eb462a652f9239a6c9e92c479dd06 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 09:06:12 +0900 Subject: [PATCH 052/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index a213ba723b487..79852409f909d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -317,7 +317,7 @@ Podアンチアフィニティを使用する理由は他にもあります。 ## nodeName -`nodeName`はアフィニティや`nodeSelector`よりも直接的なNode選択形式になります。`nodeName`はPod仕様(spec)のフィールドです。`nodeName`フィールドが空でない場合、スケジューラーはPodを考慮せずに、指定されたNodeにあるkubeletはそのNodeにPodを配置しようとします。`nodeName`を使用すると、`nodeSelector`やアフィニティおよびアンチアフィニティルールを使用するよりも優先されます。 +`nodeName`はアフィニティや`nodeSelector`よりも直接的なNode選択形式になります。`nodeName`はPod仕様(spec)内のフィールドです。`nodeName`フィールドが空でない場合、スケジューラーはPodを考慮せずに、指定されたNodeにあるkubeletがそのNodeにPodを配置しようとします。`nodeName`を使用すると、`nodeSelector`やアフィニティおよびアンチアフィニティルールを使用するよりも優先されます。 `nodeName`を使ってNodeを選択する場合の制約は以下の通りです: From 17971a75e1b9d0515d0416b0e3e229c05f5058da Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 13:38:40 +0900 Subject: [PATCH 053/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md --- content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 79852409f909d..4404abd8762ae 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -157,7 +157,7 @@ profiles: `addedAffinity`はエンドユーザーには見えないので、その動作はエンドユーザーにとって予期しないものになる可能性があります。スケジューラープロファイル名と明確な相関関係のあるNodeラベルを使用すべきです。 {{< note >}} -[DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。 +[DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。 {{< /note >}} ### Pod間のアフィニティとアンチアフィニティ From 8e42d86aa682d30e378b5e4a2eaa5cb5dbe5c72b Mon Sep 17 00:00:00 2001 From: utkarsh-singh1 Date: Tue, 7 Mar 2023 11:29:35 +0530 Subject: [PATCH 054/215] Updated french documrnt web-ui-dashboard.md Signed-off-by: utkarsh-singh1 --- .../docs/tasks/access-application-cluster/web-ui-dashboard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md index ba5d296adb5f8..539bec39f9ea3 100644 --- a/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -29,7 +29,7 @@ L'interface utilisateur du tableau de bord n'est pas déployée par défaut. Pour le déployer, exécutez la commande suivante: ```text -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/charts/recommended.yaml ``` ## Accès à l'interface utilisateur du tableau de bord From 20a3712cc78d0bad40a0a217aec33be7b09114a9 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:53:50 +0900 Subject: [PATCH 055/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index da2671ca776e3..876c1276536be 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -33,7 +33,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 YAMLファイルに基づいてDaemonSetを作成します。 ``` -kubectl apply -f https://k8s.io/examples/controllers/daemonset.yal +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` ### 必須のフィールド From d47ec5d44992594ceb068cac40ba5706644980ac Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:54:00 +0900 Subject: [PATCH 056/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 876c1276536be..6f9dab1607d5c 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -55,7 +55,7 @@ Podに対する必須のフィールドに加えて、DaemonSet内のPodテン DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。 -### Podセレクター +### Podセレクター `.spec.selector`フィールドはPodセレクターとなります。これは[Job](/ja/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 From 5ef089cdca11f4407991db1102d6c7255b960913 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:54:31 +0900 Subject: [PATCH 057/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 6f9dab1607d5c..d0f775db2f5a5 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -78,7 +78,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts ## Daemon Podがどのようにスケジューリングされるか -DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働させることを保証します。DaemonSetコントローラーは対象となる各Nodeに対してPodを作成し、ターゲットホストに一致するようにPodの`spec.affinity.nodeAffinity`フィールドを追加します。Podが作成されると、デフォルトのスケジューラーが慣例的に引き継ぎ、`.spec.nodeName`を設定することでPodをターゲットホストにバインドします。新しいNodeに適合できない場合、デフォルトスケジューラーは新しいPodの[優先度](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)に基づいて既存Podのいくつかを先取り（退避）させることがあります。 +DaemonSetは、全ての利用可能なNodeがPodのコピーを稼働させることを保証します。DaemonSetコントローラーは対象となる各Nodeに対してPodを作成し、ターゲットホストに一致するようにPodの`spec.affinity.nodeAffinity`フィールドを追加します。Podが作成されると、通常はデフォルトのスケジューラーが引き継ぎ、`.spec.nodeName`を設定することでPodをターゲットホストにバインドします。新しいNodeに適合できない場合、デフォルトスケジューラーは新しいPodの[優先度](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)に基づいて、既存Podのいくつかを先取り(退避)させることがあります。 ユーザーは、DaemonSetの`.spec.template.spec.schedulerName`フィールドを設定することにより、DaemonSetのPodsに対して異なるスケジューラーを指定することができます。 From 74982a315514a707fb5531b2264af8c786b537cb Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:54:50 +0900 Subject: [PATCH 058/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index d0f775db2f5a5..1707ee10d73df 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -80,7 +80,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts DaemonSetは、全ての利用可能なNodeがPodのコピーを稼働させることを保証します。DaemonSetコントローラーは対象となる各Nodeに対してPodを作成し、ターゲットホストに一致するようにPodの`spec.affinity.nodeAffinity`フィールドを追加します。Podが作成されると、通常はデフォルトのスケジューラーが引き継ぎ、`.spec.nodeName`を設定することでPodをターゲットホストにバインドします。新しいNodeに適合できない場合、デフォルトスケジューラーは新しいPodの[優先度](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)に基づいて、既存Podのいくつかを先取り(退避)させることがあります。 -ユーザーは、DaemonSetの`.spec.template.spec.schedulerName`フィールドを設定することにより、DaemonSetのPodsに対して異なるスケジューラーを指定することができます。 +ユーザーは、DaemonSetの`.spec.template.spec.schedulerName`フィールドを設定することにより、DaemonSetのPodに対して異なるスケジューラーを指定することができます。 `.spec.template.spec.affinity.nodeAffinity`フィールド(指定された場合)で指定された元のNodeアフィニティは、DaemonSetコントローラーが対象Nodeを評価する際に考慮されますが、作成されたPod上では対象Nodeの名前と一致するNodeアフィニティに置き換わります。 From 93ffc31f3cf49e63e1d7b3fd97efaa4854f8e248 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:55:05 +0900 Subject: [PATCH 059/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 1707ee10d73df..45eb01b951853 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -108,7 +108,7 @@ text="Toleration" term_id="toleration" >}}を自動的に追加します: | [`node.kubernetes.io/not-ready`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-not-ready) | `NoExecute` | 健康でないNodeや、Podを受け入れる準備ができていないNodeにDaemonSet Podをスケジュールできるように設定します。そのようなNode上で動作しているDaemonSet Podは退避されることがありません。 | | [`node.kubernetes.io/unreachable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable) | `NoExecute` | Nodeコントローラーから到達できないNodeにDaemonSet Podをスケジュールできるように設定します。このようなNode上で動作しているDaemonSet Podは、退避されません。 | | [`node.kubernetes.io/disk-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure) | `NoSchedule` | ディスク不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | -| [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | メモリ不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | メモリー不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 処理プレッシャー問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/unschedulable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | スケジューリング不可能なNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **ホストネットワークを要求するDaemonSet Podにのみ追加できます**、つまり`spec.hostNetwork: true`と設定されているPodです。このようなDaemonSet Podは、ネットワークが利用できないNodeにスケジュールできるように設定できます。| From b942bf663538a55870137e2c91231778dca3bc66 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:55:22 +0900 Subject: [PATCH 060/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 45eb01b951853..fb3196dbd1267 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -109,7 +109,7 @@ text="Toleration" term_id="toleration" >}}を自動的に追加します: | [`node.kubernetes.io/unreachable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable) | `NoExecute` | Nodeコントローラーから到達できないNodeにDaemonSet Podをスケジュールできるように設定します。このようなNode上で動作しているDaemonSet Podは、退避されません。 | | [`node.kubernetes.io/disk-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure) | `NoSchedule` | ディスク不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | メモリー不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | -| [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 処理プレッシャー問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | +| [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 処理負荷に問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/unschedulable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | スケジューリング不可能なNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **ホストネットワークを要求するDaemonSet Podにのみ追加できます**、つまり`spec.hostNetwork: true`と設定されているPodです。このようなDaemonSet Podは、ネットワークが利用できないNodeにスケジュールできるように設定できます。| From b3db57752e6034f1dc255615bc3c396d79da9ce0 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:55:51 +0900 Subject: [PATCH 061/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index fb3196dbd1267..a9f7fdf1b1956 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -117,7 +117,7 @@ text="Toleration" term_id="toleration" >}}を自動的に追加します: DaemonSetのPodテンプレートで定義すれば、DaemonSetのPodに独自のTolerationを追加することも可能です。 -DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule`Tolerationを自動的に設定するため、Kubernetesは _スケジューリング不可能_ としてマークされているNodeでDaemonSet Podを実行することが可能です。 +DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule`のTolerationを自動的に設定するため、Kubernetesは _スケジューリング不可能_ としてマークされているNodeでDaemonSet Podを実行することが可能です。 [クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)のような重要なNodeレベル機能をDaemonSetで提供する場合、KubernetesがDaemonSet PodをNodeが準備完了になる前に配置することは有用です。 例えば、その特別なTolerationがなければ、ネットワークプラグインがそこで実行されていないためにNodeが準備完了としてマークされず、同時にNodeがまだ準備完了でないためにそのNode上でネットワークプラグインが実行されていないというデッドロック状態に陥ってしまう可能性があるのです。 From d68da8ec5d5e8048b765ee4df872de66905eaad3 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:56:11 +0900 Subject: [PATCH 062/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index a9f7fdf1b1956..f5222384b148f 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -119,7 +119,7 @@ DaemonSetのPodテンプレートで定義すれば、DaemonSetのPodに独自 DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule`のTolerationを自動的に設定するため、Kubernetesは _スケジューリング不可能_ としてマークされているNodeでDaemonSet Podを実行することが可能です。 -[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)のような重要なNodeレベル機能をDaemonSetで提供する場合、KubernetesがDaemonSet PodをNodeが準備完了になる前に配置することは有用です。 +[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)のような重要なNodeレベルの機能をDaemonSetで提供する場合、KubernetesがDaemonSet PodをNodeが準備完了になる前に配置することは有用です。 例えば、その特別なTolerationがなければ、ネットワークプラグインがそこで実行されていないためにNodeが準備完了としてマークされず、同時にNodeがまだ準備完了でないためにそのNode上でネットワークプラグインが実行されていないというデッドロック状態に陥ってしまう可能性があるのです。 ## Daemon Podとのコミュニケーション From 60ab92635e8495c53b6bf6ddcd727364fc3f5a29 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:56:27 +0900 Subject: [PATCH 063/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index f5222384b148f..09e361c6a9977 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -129,7 +129,7 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ - **Push**: DaemonSet内のPodは統計データベースなどの他のサービスに対して更新情報を送信するように設定されます。クライアントは持っていません。 - **NodeIPとKnown Port**: PodがNodeIPを介して疎通できるようにするため、DaemonSet内のPodは`hostPort`を使用できます。慣例により、クライアントはNodeIPのリストとポートを知っています。 - **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。 -- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。(特定のNodeにアクセスする方法がありません。) +- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。(特定のNodeにアクセスする方法はありません。) ## DaemonSetの更新 From 78f342cc82e1c1345b31a41a14a28d025fff9232 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:56:47 +0900 Subject: [PATCH 064/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 09e361c6a9977..8a1a3090418e4 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -111,7 +111,7 @@ text="Toleration" term_id="toleration" >}}を自動的に追加します: | [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | メモリー不足問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 処理負荷に問題のあるNodeにDaemonSet Podをスケジュールできるように設定します。 | | [`node.kubernetes.io/unschedulable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | スケジューリング不可能なNodeにDaemonSet Podをスケジュールできるように設定します。 | -| [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **ホストネットワークを要求するDaemonSet Podにのみ追加できます**、つまり`spec.hostNetwork: true`と設定されているPodです。このようなDaemonSet Podは、ネットワークが利用できないNodeにスケジュールできるように設定できます。| +| [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **ホストネットワークを要求するDaemonSet Podにのみ追加できます**、つまり`spec.hostNetwork: true`と設定されているPodです。このようなDaemonSet Podは、ネットワークが利用できないNodeにスケジュールできるように設定します。| {{< /table >}} From 947170af0bada3cf9800547f7a64ac2b20841de6 Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:57:00 +0900 Subject: [PATCH 065/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 8a1a3090418e4..d813d45b032d6 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -124,7 +124,7 @@ DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule` ## Daemon Podとのコミュニケーション -DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです。: +DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです: - **Push**: DaemonSet内のPodは統計データベースなどの他のサービスに対して更新情報を送信するように設定されます。クライアントは持っていません。 - **NodeIPとKnown Port**: PodがNodeIPを介して疎通できるようにするため、DaemonSet内のPodは`hostPort`を使用できます。慣例により、クライアントはNodeIPのリストとポートを知っています。 From a37532c0b85e93687e6804379f6e98510fe280cc Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:58:02 +0900 Subject: [PATCH 066/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index d813d45b032d6..c5b129442e56a 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -149,7 +149,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd` - アプリケーションと同じ方法でデーモンの監視とログの管理ができる。 - デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。 -- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離を促進します。しかし、これはPod内でなく、コンテナ内でデーモンを稼働させることにより可能です。 +- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離性が高まります。ただし、これはPod内ではなく、コンテナ内でデーモンを稼働させることでも可能です。 ### ベアPod From 646bc62495d1847c221e440562820e22265fda3c Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Tue, 7 Mar 2023 17:59:27 +0900 Subject: [PATCH 067/215] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index c5b129442e56a..f0f9379993e22 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -164,7 +164,7 @@ Kubeletによって監視されているディレクトリに対してファイ DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 -DaemonSetがNodeレベルの機能を提供し、他のPodがその特定のNodeで正しく動作するようにする場合、Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 +DaemonSetがNodeレベルの機能を提供し、他のPodがその特定のNodeで正しく動作するようにする場合、Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合にDaemonSetを使ってください。 例えば、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)には、DaemonSetとして動作するコンポーネントが含まれていることがよくあります。DaemonSetコンポーネントは、それが動作しているNodeでクラスターネットワークが動作していることを確認します。 From bccd515e3ea8ecc79a06cb7ae71204085225baca Mon Sep 17 00:00:00 2001 From: windsonsea Date: Tue, 7 Mar 2023 18:06:23 +0800 Subject: [PATCH 068/215] [zh] sync organize-cluster-access-kubeconfig.md --- .../organize-cluster-access-kubeconfig.md | 108 +++++++++--------- 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index c181e32fcef7b..d89e7c7f1f3f8 100644 --- a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -20,27 +20,23 @@ of a cluster. 使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。 `kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。 - -{{< note >}} -用于配置集群访问的文件称为“kubeconfig 文件”。 -这是引用配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件 +用于配置集群访问的文件称为 **kubeconfig 文件**。 +这是引用到配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件。 {{< /note >}} - -{{< warning >}} -只使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。 -如果必须使用不受信任的 kubeconfig 文件，请首先像检查 shell 脚本一样仔细检查它。 +请务必仅使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。 +如果必须使用不受信任的 kubeconfig 文件，请首先像检查 Shell 脚本一样仔细检查此文件。 {{< /warning>}} -有关创建和指定 kubeconfig 文件的分步说明，请参阅 -[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 +有关创建和指定 kubeconfig 文件的分步说明， +请参阅[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 -## 支持多集群、用户和身份认证机制 +## 支持多集群、用户和身份认证机制 {#support-clusters-users-and-authn} -## 上下文（Context） +## 上下文（Context） {#context} -选择当前上下文 +选择当前上下文： ```shell kubectl config use-context @@ -116,7 +112,7 @@ kubectl config use-context -## KUBECONFIG 环境变量 +## KUBECONFIG 环境变量 {#kubeconfig-env-var} `KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。 -对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。 -`KUBECONFIG` 环境变量不是必要的。 -如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。 +对于 Linux 和 Mac，此列表以英文冒号分隔。对于 Windows，此列表以英文分号分隔。 +`KUBECONFIG` 环境变量不是必需的。 +如果 `KUBECONFIG` 环境变量不存在，`kubectl` 将使用默认的 kubeconfig 文件：`$HOME/.kube/config`。 -如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。 +如果 `KUBECONFIG` 环境变量存在，`kubectl` 将使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。 -## 合并 kubeconfig 文件 +## 合并 kubeconfig 文件 {#merge-kubeconfig-files} -如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。 +如前所述，输出可能来自单个 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。 - 有关设置 `KUBECONFIG` 环境变量的示例，请参阅 - [设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 + --> + 有关设置 `KUBECONFIG` 环境变量的示例， + 请参阅[设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 - - 否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。 + --> + 否则，使用默认的 kubeconfig 文件（`$HOME/.kube/config`），不进行合并。 2. 根据此链中的第一个匹配确定要使用的上下文。 - 1. 如果存在，使用 `--context` 命令行参数。 + 1. 如果存在上下文，则使用 `--context` 命令行参数。 2. 使用合并的 kubeconfig 文件中的 `current-context`。 - + --> 这种场景下允许空上下文。 -3. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。 +3. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户， + 这将运行两次：一次用于用户，一次用于集群。 - 1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。 - 2. 如果上下文非空，从上下文中获取用户或集群。 + 1. 如果存在用户或集群，则使用命令行参数：`--user` 或者 `--cluster`。 + 2. 如果上下文非空，则从上下文中获取用户或集群。 - + --> 这种场景下用户和集群可以为空。 -4. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用： +4. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。 + 基于此链构建每个集群信息；第一个匹配项会被采用： - 1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。 - 2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。 + 1. 如果存在集群信息，则使用命令行参数：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`。 + 2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用这些属性。 3. 如果没有 server 配置，则配置无效。 -5. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术： +5. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但对于每个用户只允许使用一种身份认证技术： - 1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。 + 1. 如果存在用户信息，则使用命令行参数：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`。 2. 使用合并的 kubeconfig 文件中的 `user` 字段。 3. 如果存在两种冲突技术，则配置无效。 6. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。 @@ -273,7 +273,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: -## 文件引用 +## 文件引用 {#file-reference} kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。 命令行上的文件引用是相对于当前工作目录的。 -在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。 +在 `$HOME/.kube/config` 中，相对路径按相对路径存储，而绝对路径按绝对路径存储。 -## 代理 +## 代理 {#proxy} 你可以在 `kubeconfig` 文件中，为每个集群配置 `proxy-url` 来让 `kubectl` 使用代理，例如： From f5bb98716ec08b77242b05d996cb4daf357e103c Mon Sep 17 00:00:00 2001 From: marianogg9 Date: Tue, 7 Mar 2023 13:01:17 +0100 Subject: [PATCH 069/215] rephrased finalizers.md --- content/es/docs/reference/glossary/finalizer.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/es/docs/reference/glossary/finalizer.md b/content/es/docs/reference/glossary/finalizer.md index 765ab36a83ad0..af8367da7b62d 100644 --- a/content/es/docs/reference/glossary/finalizer.md +++ b/content/es/docs/reference/glossary/finalizer.md @@ -9,9 +9,8 @@ short_description: > aka: tags: - fundamental -- operation --- -Los finalizadores son atributos de un namespace que dictan a Kubernetes a +Los finalizadores son atributos de un namespace que instruyen a Kubernetes a esperar a que ciertas condiciones sean satisfechas antes que pueda borrar definitivamente un objeto que ha sido marcado para eliminarse. Los finalizadores alertan a los {{}} From a45d7fe2d30a1e2ca63b7c4cd9ba111701667d2e Mon Sep 17 00:00:00 2001 From: Adrian Reber Date: Thu, 2 Mar 2023 17:14:27 +0100 Subject: [PATCH 070/215] Add blog post about forensic container analysis Co-authored-by: Tim Bannister Signed-off-by: Adrian Reber --- .../index.md | 373 ++++++++++++++++++ 1 file changed, 373 insertions(+) create mode 100644 content/en/blog/_posts/2023-03-10-forensic-container-analysis/index.md diff --git a/content/en/blog/_posts/2023-03-10-forensic-container-analysis/index.md b/content/en/blog/_posts/2023-03-10-forensic-container-analysis/index.md new file mode 100644 index 0000000000000..7edff1196a2f7 --- /dev/null +++ b/content/en/blog/_posts/2023-03-10-forensic-container-analysis/index.md @@ -0,0 +1,373 @@ +--- +layout: blog +title: "Forensic container analysis" +date: 2023-03-10 +slug: forensic-container-analysis +--- + +**Authors:** Adrian Reber (Red Hat) + +In my previous article, [Forensic container checkpointing in +Kubernetes][forensic-blog], I introduced checkpointing in Kubernetes +and how it has to be setup and how it can be used. The name of the +feature is Forensic container checkpointing, but I did not go into +any details how to do the actual analysis of the checkpoint created by +Kubernetes. In this article I want to provide details how the +checkpoint can be analyzed. + +Checkpointing is still an alpha feature in Kubernetes and this article +wants to provide a preview how the feature might work in the future. + +## Preparation + +Details about how to configure Kubernetes and the underlying CRI implementation +to enable checkpointing support can be found in my [Forensic container +checkpointing in Kubernetes][forensic-blog] article. + +As an example I prepared a container image (`quay.io/adrianreber/counter:blog`) +which I want to checkpoint and then analyze in this article. This container allows +me to create files in the container and also store information in memory which +I later want to find in the checkpoint. + +To run that container I need a pod, and for this example I am using the following Pod manifest: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: counters +spec: + containers: + - name: counter + image: quay.io/adrianreber/counter:blog +``` + +This results in a container called `counter` running in a pod called `counters`. + +Once the container is running I am performing following actions with that +container: + +```console +$ kubectl get pod counters --template '{{.status.podIP}}' +10.88.0.25 +$ curl 10.88.0.25:8088/create?test-file +$ curl 10.88.0.25:8088/secret?RANDOM_1432_KEY +$ curl 10.88.0.25:8088 +``` + +The first access creates a file called `test-file` with the content `test-file` +in the container and the second access stores my secret information +(`RANDOM_1432_KEY`) somewhere in the container's memory. The last access just +adds an additional line to the internal log file. + +The last step before I can analyze the checkpoint it to tell Kubernetes to create +the checkpoint. As described in the previous article this requires access to the +*kubelet* only `checkpoint` API endpoint. + +For a container named *counter* in a pod named *counters* in a namespace named +*default* the *kubelet* API endpoint is reachable at: + +```shell +# run this on the node where that Pod is executing +curl -X POST "https://localhost:10250/checkpoint/default/counters/counter" +``` + +For completeness the following `curl` command-line options are necessary to +have `curl` accept the *kubelet*'s self signed certificate and authorize the +use of the *kubelet* `checkpoint` API: + +```shell +--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key +``` + +Once the checkpointing has finished the checkpoint should be available at +`/var/lib/kubelet/checkpoints/checkpoint-_--.tar` + +In the following steps of this article I will use the name `checkpoint.tar` +when analyzing the checkpoint archive. + +## Checkpoint archive analysis using `checkpointctl` + +To get some initial information about the checkpointed container I am using the +tool [checkpointctl][checkpointctl] like this: + +```console +$ checkpointctl show checkpoint.tar --print-stats ++-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+ +| CONTAINER | IMAGE | ID | RUNTIME | CREATED | ENGINE | IP | CHKPT SIZE | ROOT FS DIFF SIZE | ++-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+ +| counter | quay.io/adrianreber/counter:blog | 059a219a22e5 | runc | 2023-03-02T06:06:49 | CRI-O | 10.88.0.23 | 8.6 MiB | 3.0 KiB | ++-----------+----------------------------------+--------------+---------+---------------------+--------+------------+------------+-------------------+ +CRIU dump statistics ++---------------+-------------+--------------+---------------+---------------+---------------+ +| FREEZING TIME | FROZEN TIME | MEMDUMP TIME | MEMWRITE TIME | PAGES SCANNED | PAGES WRITTEN | ++---------------+-------------+--------------+---------------+---------------+---------------+ +| 100809 us | 119627 us | 11602 us | 7379 us | 7800 | 2198 | ++---------------+-------------+--------------+---------------+---------------+---------------+ +``` + +This gives me already some information about the checkpoint in that checkpoint +archive. I can see the name of the container, information about the container +runtime and container engine. It also lists the size of the checkpoint (`CHKPT +SIZE`). This is mainly the size of the memory pages included in the checkpoint, +but there is also information about the size of all changed files in the +container (`ROOT FS DIFF SIZE`). + +The additional parameter `--print-stats` decodes information in the checkpoint +archive and displays them in the second table (*CRIU dump statistics*). This +information is collected during checkpoint creation and gives an overview how much +time CRIU needed to checkpoint the processes in the container and how many +memory pages were analyzed and written during checkpoint creation. + +## Digging deeper + +With the help of `checkpointctl` I am able to get some high level information +about the checkpoint archive. To be able to analyze the checkpoint archive +further I have to extract it. The checkpoint archive is a *tar* archive and can +be extracted with the help of `tar xf checkpoint.tar`. + +Extracting the checkpoint archive will result in following files and directories: + +* `bind.mounts` - this file contains information about bind mounts and is needed + during restore to mount all external files and directories at the right location +* `checkpoint/` - this directory contains the actual checkpoint as created by + CRIU +* `config.dump` and `spec.dump` - these files contain metadata about the container + which is needed during restore +* `dump.log` - this file contains the debug output of CRIU created during + checkpointing +* `stats-dump` - this file contains the data which is used by `checkpointctl` + to display dump statistics (`--print-stats`) +* `rootfs-diff.tar` - this file contains all changed files on the container's + file-system + +### File-system changes - `rootfs-diff.tar` + +The first step to analyze the container's checkpoint further is to look at +the files that have changed in my container. This can be done by looking at the +file `rootfs-diff.tar`: + +```console +$ tar xvf rootfs-diff.tar +home/counter/logfile +home/counter/test-file +``` + +Now the files that changed in the container can be studied: + +```console +$ cat home/counter/logfile +10.88.0.1 - - [02/Mar/2023 06:07:29] "GET /create?test-file HTTP/1.1" 200 - +10.88.0.1 - - [02/Mar/2023 06:07:40] "GET /secret?RANDOM_1432_KEY HTTP/1.1" 200 - +10.88.0.1 - - [02/Mar/2023 06:07:43] "GET / HTTP/1.1" 200 - +$ cat home/counter/test-file +test-file  +``` + +Compared to the container image (`quay.io/adrianreber/counter:blog`) this +container is based on, I can see that the file `logfile` contains information +about all access to the service the container provides and the file `test-file` +was created just as expected. + +With the help of `rootfs-diff.tar` it is possible to inspect all files that +were created or changed compared to the base image of the container. + +### Analyzing the checkpointed processes - `checkpoint/` + +The directory `checkpoint/` contains data created by CRIU while checkpointing +the processes in the container. The content in the directory `checkpoint/` +consists of different [image files][image-files] which can be analyzed with the +help of the tool [CRIT][crit] which is distributed as part of CRIU. + +First lets get an overview of the processes inside of the container: + +```console +$ crit show checkpoint/pstree.img | jq .entries[].pid +1 +7 +8 +``` + +This output means that I have three processes inside of the container's PID +namespace with the PIDs: 1, 7, 8 + +This is only the view from the inside of the container's PID namespace. During +restore exactly these PIDs will be recreated. From the outside of the +container's PID namespace the PIDs will change after restore. + +The next step is to get some additional information about these three processes: + +```console +$ crit show checkpoint/core-1.img | jq .entries[0].tc.comm +"bash" +$ crit show checkpoint/core-7.img | jq .entries[0].tc.comm +"counter.py" +$ crit show checkpoint/core-8.img | jq .entries[0].tc.comm +"tee" +``` + +This means the three processes in my container are `bash`, `counter.py` (a Python +interpreter) and `tee`. For details about the parent child relations of these processes there +is more data to be analyzed in `checkpoint/pstree.img`. + +Let's compare the so far collected information to the still running container: + +```console +$ crictl inspect --output go-template --template "{{(index .info.pid)}}" 059a219a22e56 +722520 +$ ps auxf | grep -A 2 722520 +fedora 722520 \_ bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile +fedora 722541 \_ /usr/bin/python3 /home/counter/counter.py +fedora 722542 \_ /usr/bin/coreutils --coreutils-prog-shebang=tee /usr/bin/tee /home/counter/logfile +$ cat /proc/722520/comm +bash +$ cat /proc/722541/comm +counter.py +$ cat /proc/722542/comm +tee +``` + +In this output I am first retrieving the PID of the first process in the +container and then I am looking for that PID and child processes on the system +where the container is running. I am seeing three processes and the first one is +"bash" which is PID 1 inside of the containers PID namespace. Then I am looking +at `/proc//comm` and I can find the exact same value +as in the checkpoint image. + +Important to remember is that the checkpoint will contain the view from within the +container's PID namespace because that information is important to restore the +processes. + +One last example of what `crit` can tell us about the container is the information +about the UTS namespace: + +```console +$ crit show checkpoint/utsns-12.img +{ + "magic": "UTSNS", + "entries": [ + { + "nodename": "counters", + "domainname": "(none)" + } + ] +} +``` + +This tells me that the hostname inside of the UTS namespace is `counters`. + +For every resource CRIU collected during checkpointing the `checkpoint/` +directory contains corresponding image files which can be analyzed with the help +of `crit`. + +#### Looking at the memory pages + +In addition to the information from CRIU that can be decoded with the help +of CRIT, there are also files containing the raw memory pages written by +CRIU to disk: + +```console +$ ls checkpoint/pages-* +checkpoint/pages-1.img checkpoint/pages-2.img checkpoint/pages-3.img +``` + +When I initially used the container I stored a random key (`RANDOM_1432_KEY`) +somewhere in the memory. Let see if I can find it: + +```console +$ grep -ao RANDOM_1432_KEY checkpoint/pages-* +checkpoint/pages-2.img:RANDOM_1432_KEY +``` + +And indeed, there is my data. This way I can easily look at the content +of all memory pages of the processes in the container, but it is also +important to remember that anyone that can access the checkpoint +archive has access to all information that was stored in the memory of the +container's processes. + +#### Using gdb for further analysis + +Another possibility to look at the checkpoint images is `gdb`. The CRIU repository +contains the script [coredump][criu-coredump] which can convert a checkpoint +into a coredump file: + +```console +$ /home/criu/coredump/coredump-python3 +$ ls -al core* +core.1 core.7 core.8 +``` + +Running the `coredump-python3` script will convert the checkpoint images into +one coredump file for each process in the container. Using `gdb` I can also look +at the details of the processes: + +```console +$ echo info registers | gdb --core checkpoint/core.1 -q + +[New LWP 1] + +Core was generated by `bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile'. + +#0 0x00007fefba110198 in ?? () +(gdb) +rax 0x3d 61 +rbx 0x8 8 +rcx 0x7fefba11019a 140667595587994 +rdx 0x0 0 +rsi 0x7fffed9c1110 140737179816208 +rdi 0xffffffff 4294967295 +rbp 0x1 0x1 +rsp 0x7fffed9c10e8 0x7fffed9c10e8 +r8 0x1 1 +r9 0x0 0 +r10 0x0 0 +r11 0x246 582 +r12 0x0 0 +r13 0x7fffed9c1170 140737179816304 +r14 0x0 0 +r15 0x0 0 +rip 0x7fefba110198 0x7fefba110198 +eflags 0x246 [ PF ZF IF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +``` + +In this example I can see the value of all registers as they were during +checkpointing and I can also see the complete command-line of my container's PID +1 process: `bash -c /home/counter/counter.py 2>&1 | tee /home/counter/logfile` + +## Summary + +With the help of container checkpointing, it is possible to create a +checkpoint of a running container without stopping the container and without the +container knowing that it was checkpointed. The result of checkpointing a +container in Kubernetes is a checkpoint archive; using different tools like +`checkpointctl`, `tar`, `crit` and `gdb` the checkpoint can be analyzed. Even +with simple tools like `grep` it is possible to find information in the +checkpoint archive. + +The different examples I have shown in this article how to analyze a checkpoint +are just the starting point. Depending on your requirements it is possible to +look at certain things in much more detail, but this article should give you an +introduction how to start the analysis of your checkpoint. + +## How do I get involved? + +You can reach SIG Node by several means: + +* Slack: [#sig-node][slack-sig-node] +* Slack: [#sig-security][slack-sig-security] +* [Mailing list][sig-node-ml] + +[forensic-blog]: https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/ +[checkpointctl]: https://github.com/checkpoint-restore/checkpointctl +[image-files]: https://criu.org/Images +[crit]: https://criu.org/CRIT +[slack-sig-node]: https://kubernetes.slack.com/messages/sig-node +[slack-sig-security]: https://kubernetes.slack.com/messages/sig-security +[sig-node-ml]: https://groups.google.com/forum/#!forum/kubernetes-sig-node +[criu-coredump]: https://github.com/checkpoint-restore/criu/tree/criu-dev/coredump From 4db706cff7ebe43fe550454352796727ec860a48 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 8 Mar 2023 00:41:57 +0200 Subject: [PATCH 071/215] [pt] Change shell to console for code snippet --- .../configure-pod-container/configure-volume-storage.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/pt-br/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/pt-br/docs/tasks/configure-pod-container/configure-volume-storage.md index 8687c19ab7485..e0cbfa57a2bce 100644 --- a/content/pt-br/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/pt-br/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -49,7 +49,7 @@ reinicie. Aqui está o arquivo de configuração para o pod: A saída se parece com isso: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s ``` @@ -77,7 +77,7 @@ reinicie. Aqui está o arquivo de configuração para o pod: A saída é semelhante a esta: - ```shell + ```console USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash @@ -95,7 +95,7 @@ reinicie. Aqui está o arquivo de configuração para o pod: 1. No seu terminal original, preste atenção nas mudanças no Pod do Redis. Eventualmente, você vai ver algo assim: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s redis 0/1 Completed 0 6m From 6798680f99bbe2d9b4b779e567fbb4242a65a423 Mon Sep 17 00:00:00 2001 From: Adrian Reber Date: Tue, 7 Mar 2023 19:30:02 +0100 Subject: [PATCH 072/215] Add link to checkpointing follow-up article Co-authored-by: Tim Bannister Signed-off-by: Adrian Reber --- .../2022-12-05-forensic-container-checkpointing/index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md b/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md index 14293556a43ba..9cd3832e5f44d 100644 --- a/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md +++ b/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md @@ -207,3 +207,11 @@ and without losing the state of the containers in that Pod. You can reach SIG Node by several means: - Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node) - [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node) + +## Further reading + +Please see the follow-up article [Forensic container +analysis][forensic-container-analysis] for details on how a container checkpoint +can be analyzed. + +[forensic-container-analysis]: /blog/2023/03/10/forensic-container-analysis/ From e7e4de3a0fdb154ee446999040b6fc31085ac533 Mon Sep 17 00:00:00 2001 From: Dipesh Rawat Date: Wed, 8 Mar 2023 13:37:12 +0000 Subject: [PATCH 073/215] Added info for shortcode in style guide (#39764) * Add info for codenew shortcode in style guide Signed-off-by: Dipesh Rawat * Update content/en/docs/contribute/style/style-guide.md Co-authored-by: Tim Bannister * Addressed feedback comments Signed-off-by: Dipesh Rawat * Update content/en/docs/contribute/style/hugo-shortcodes/index.md Co-authored-by: Brad Topol * Update content/en/docs/contribute/style/hugo-shortcodes/index.md Co-authored-by: Brad Topol --------- Signed-off-by: Dipesh Rawat Co-authored-by: Tim Bannister Co-authored-by: Brad Topol --- .../contribute/style/hugo-shortcodes/index.md | 27 +++++++++++++++++++ .../en/docs/contribute/style/style-guide.md | 1 + 2 files changed, 28 insertions(+) diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index 2d751f73f30c0..a6ba992ee785b 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -271,6 +271,33 @@ Renders to: {{< tab name="JSON File" include="podtemplate.json" />}} {{< /tabs >}} +### Source code files + +You can use the `{{}}` shortcode to embed the contents of file in a code block to allow users to download or copy its content to their clipboard. This shortcode is used when the contents of the sample file is generic and reusable, and you want the users to try it out themselves. + +This shortcode takes in two named parameters: `language` and `file`. The mandatory parameter `file` is used to specify the path to the file being displayed. The optional parameter `language` is used to specify the programming language of the file. If the `language` parameter is not provided, the shortcode will attempt to guess the language based on the file extension. + +For example: + +```none +{{}} +``` + +The output is: + +{{< codenew language="yaml" file="application/deployment-scale.yaml" >}} + +When adding a new sample file, such as a YAML file, create the file in one of the `/examples/` subdirectories where `` is the language for the page. In the markdown of your page, use the `codenew` shortcode: + +```none +{{/example-yaml>" */>}} +``` +where `` is the path to the sample file to include, relative to the `examples` directory. The following shortcode references a YAML file located at `/content/en/examples/configmap/configmaps.yaml`. + +```none +{{}} +``` + ## Third party content marker Running Kubernetes requires third-party software. For example: you diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index dce6eb291ff30..c7f020a5fc1a2 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -631,4 +631,5 @@ These steps ... | These simple steps ... * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). * Learn about [using page templates](/docs/contribute/style/page-content-types/). +* Learn about [custom hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). * Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). From 08aaa3fce587ae988af7c8912ddfd98509e6d269 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marko=20Mudrini=C4=87?= Date: Wed, 8 Mar 2023 14:51:08 +0100 Subject: [PATCH 074/215] Add February patch releases to the calendar MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Marko Mudrinić --- data/releases/schedule.yaml | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 61d186ef8f0e8..df51c5a73af92 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -4,10 +4,15 @@ schedules: maintenanceModeStartDate: 2023-12-28 endOfLifeDate: 2024-02-28 next: - release: 1.26.2 - cherryPickDeadline: 2023-02-10 - targetDate: 2023-02-15 + release: 1.26.3 + cherryPickDeadline: 2023-03-10 + targetDate: 2023-03-15 previousPatches: + - release: 1.26.2 + cherryPickDeadline: 2023-02-10 + targetDate: 2023-02-15 + note: >- + [Some container images might be **unsigned** due to a temporary issue with the promotion process](https://groups.google.com/a/kubernetes.io/g/dev/c/MwSx761slM0/m/4ajkeUl0AQAJ) - release: 1.26.1 cherryPickDeadline: 2023-01-13 targetDate: 2023-01-18 @@ -19,10 +24,15 @@ schedules: maintenanceModeStartDate: 2023-08-28 endOfLifeDate: 2023-10-28 next: - release: 1.25.7 - cherryPickDeadline: 2023-02-10 - targetDate: 2023-02-15 + release: 1.25.8 + cherryPickDeadline: 2023-03-10 + targetDate: 2023-03-15 previousPatches: + - release: 1.25.7 + cherryPickDeadline: 2023-02-10 + targetDate: 2023-02-15 + note: >- + [Some container images might be **unsigned** due to a temporary issue with the promotion process](https://groups.google.com/a/kubernetes.io/g/dev/c/MwSx761slM0/m/4ajkeUl0AQAJ) - release: 1.25.6 cherryPickDeadline: 2023-01-13 targetDate: 2023-01-18 @@ -53,10 +63,15 @@ schedules: maintenanceModeStartDate: 2023-05-28 endOfLifeDate: 2023-07-28 next: - release: 1.24.11 - cherryPickDeadline: 2023-02-10 - targetDate: 2023-02-15 + release: 1.24.12 + cherryPickDeadline: 2023-03-10 + targetDate: 2023-03-15 previousPatches: + - release: 1.24.11 + cherryPickDeadline: 2023-02-10 + targetDate: 2023-02-15 + note: >- + [Some container images might be **unsigned** due to a temporary issue with the promotion process](https://groups.google.com/a/kubernetes.io/g/dev/c/MwSx761slM0/m/4ajkeUl0AQAJ) - release: 1.24.10 cherryPickDeadline: 2023-01-13 targetDate: 2023-01-18 From d86e129d6aae75df945ea55246208d49735a9338 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marko=20Mudrini=C4=87?= Date: Wed, 8 Mar 2023 14:51:47 +0100 Subject: [PATCH 075/215] Mark 1.23 as EOL MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Marko Mudrinić --- data/releases/eol.yaml | 3 ++ data/releases/schedule.yaml | 66 ------------------------------------- 2 files changed, 3 insertions(+), 66 deletions(-) diff --git a/data/releases/eol.yaml b/data/releases/eol.yaml index 64e6306a26ff9..401c871946651 100644 --- a/data/releases/eol.yaml +++ b/data/releases/eol.yaml @@ -1,4 +1,7 @@ branches: + - release: "1.23" + finalPatchRelease: "1.23.17" + endOfLifeDate: 2023-02-28 - release: "1.22" finalPatchRelease: "1.22.17" endOfLifeDate: 2022-12-08 diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index df51c5a73af92..c1cc1a8af052d 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -109,69 +109,3 @@ schedules: - release: 1.24.0 cherryPickDeadline: "" targetDate: 2022-05-03 -- release: 1.23 - releaseDate: 2021-12-07 - maintenanceModeStartDate: 2022-12-28 - endOfLifeDate: 2023-02-28 - next: - release: 1.23.17 - cherryPickDeadline: 2023-02-10 - targetDate: 2023-02-15 - previousPatches: - - release: 1.23.16 - cherryPickDeadline: 2023-01-13 - targetDate: 2023-01-18 - - release: 1.23.15 - cherryPickDeadline: 2022-12-02 - targetDate: 2022-12-08 - - release: 1.23.14 - cherryPickDeadline: 2022-11-04 - targetDate: 2022-11-09 - - release: 1.23.13 - cherryPickDeadline: 2022-10-07 - targetDate: 2022-10-12 - - release: 1.23.12 - cherryPickDeadline: 2022-09-20 - targetDate: 2022-09-21 - note: >- - [Out-of-Band release to fix the regression introduced in 1.23.11](https://groups.google.com/a/kubernetes.io/g/dev/c/tA6LNOQTR4Q/m/zL73maPTAQAJ) - - release: 1.23.11 - cherryPickDeadline: 2022-09-09 - targetDate: 2022-09-14 - note: >- - [Regression](https://groups.google.com/a/kubernetes.io/g/dev/c/tA6LNOQTR4Q/m/zL73maPTAQAJ) - - release: 1.23.10 - cherryPickDeadline: 2022-08-12 - targetDate: 2022-08-17 - - release: 1.23.9 - cherryPickDeadline: 2022-07-08 - targetDate: 2022-07-13 - - release: 1.23.8 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 - - release: 1.23.7 - cherryPickDeadline: 2022-05-20 - targetDate: 2022-05-24 - - release: 1.23.6 - cherryPickDeadline: 2022-04-08 - targetDate: 2022-04-13 - - release: 1.23.5 - cherryPickDeadline: 2022-03-11 - targetDate: 2022-03-16 - - release: 1.23.4 - cherryPickDeadline: 2022-02-11 - targetDate: 2022-02-16 - - release: 1.23.3 - cherryPickDeadline: 2022-01-24 - targetDate: 2022-01-25 - note: >- - [Out-of-Band Release](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) - - release: 1.23.2 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 - - release: 1.23.1 - cherryPickDeadline: 2021-12-14 - targetDate: 2021-12-16 - - release: 1.23.0 - cherryPickDeadline: "" - targetDate: 2021-12-07 From 5cf475c0b7fc879ac9ce80bd1f21a408befb0784 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marko=20Mudrini=C4=87?= Date: Wed, 8 Mar 2023 14:53:54 +0100 Subject: [PATCH 076/215] Add release dates for May and June MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Marko Mudrinić --- content/en/releases/patch-releases.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index dc80e19baf225..874193f3283e9 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,9 +78,10 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| February 2023 | 2023-02-10 | 2023-02-15 | | March 2023 | 2023-03-10 | 2023-03-15 | | April 2023 | 2023-04-07 | 2023-04-12 | +| May 2023 | 2023-05-12 | 2023-05-17 | +| June 2023 | 2023-06-09 | 2023-06-14 | ## Detailed Release History for Active Branches From dc201c53807cc9d61932d150d85376f84cb9e939 Mon Sep 17 00:00:00 2001 From: marianogg9 Date: Wed, 8 Mar 2023 17:16:46 +0100 Subject: [PATCH 077/215] fixed translation typo in finalizers.md Signed-off-by: marianogg9 --- .../docs/concepts/overview/working-with-objects/finalizers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/overview/working-with-objects/finalizers.md b/content/es/docs/concepts/overview/working-with-objects/finalizers.md index 04404f1e70cac..95a68f7852b57 100644 --- a/content/es/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/es/docs/concepts/overview/working-with-objects/finalizers.md @@ -46,7 +46,7 @@ previene el borrado accidental de objetos `PersistentVolume`. Cuando un objeto Cuando el Pod deja de utilizar el `PersistentVolume`, Kubernetes borra el finalizador `pv-protection` y el controlador borra el volumen. -## Referencias de dueño, etiquetas y finalizadores (#dueños-etiquetas-finalizadores) +## Referencias de dueño, etiquetas y finalizadores (#owners-labels-finalizers) Al igual que las {{}}, las [referencias de dueño](/docs/concepts/overview/working-with-objects/owners-dependents/) From 4b883eb10078304cf97eee18001b53323ddb94b7 Mon Sep 17 00:00:00 2001 From: ystkfujii Date: Wed, 8 Mar 2023 02:52:38 +0900 Subject: [PATCH 078/215] Clarify API version stability and guidelines --- .../docs/concepts/overview/kubernetes-api.md | 16 ++++++++++--- content/ja/docs/reference/using-api/_index.md | 23 ++++++++++--------- 2 files changed, 25 insertions(+), 14 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 5b6388a306adf..4fb0b6ec5a3da 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -145,7 +145,9 @@ APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[ APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。 -例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。 +例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。 +`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`バージョンが非推奨となり削除されるまで、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。 +その時点では `v1` APIを使用してオブジェクトの修正やアクセスを継続することが可能です。 ## APIの変更 @@ -156,10 +158,18 @@ Kubernetesプロジェクトは、既存のクライアントとの互換性を 基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。 -Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。 +Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。 +さらに、Kubernetesは、公式Kubernetes APIの _beta_ APIバージョン経由で永続化されたデータとの互換性を維持します。 +そして、機能が安定したときにGA APIバージョン経由でデータを変換してアクセスできることを保証します。 + +beta APIを採用した場合、APIが卒業(Graduate)したら、後続のbetaまたはstable APIに移行する必要があります。 +これを行うのに最適な時期は、オブジェクトが両方のAPIバージョンから同時にアクセスできるbeta APIが非推奨期間です。 +beta APIが非推奨期間を終えて提供されなくなったら、代替APIバージョンを使用する必要があります。 {{< note >}} -Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。アルファAPIバージョンを使っている場合、クラスタのアップグレードやAPIが変更された場合に備えて、Kubernetesのリリースノートを確認してください。 +Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。 +alpha APIバージョンを使っている場合、クラスターをアップグレードする時にKubernetesのリリースノートを確認してください。 +アップグレードのために既存のalphaオブジェクトをすべて削除する必要がある互換性の無い方法でAPIが変更される場合があります。 {{< /note >}} APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/docs/reference/using-api/#api-versioning)を参照してください。 diff --git a/content/ja/docs/reference/using-api/_index.md b/content/ja/docs/reference/using-api/_index.md index 543b78b2c84a9..caad234abbd01 100644 --- a/content/ja/docs/reference/using-api/_index.md +++ b/content/ja/docs/reference/using-api/_index.md @@ -14,7 +14,7 @@ card: このセクションでは、Kubernetes APIのリファレンス情報を提供します。 REST APIはKubernetesの基本的な構造です。 -すべての操作とコンポーネント間のと通信、および外部ユーザーのコマンドは、REST API呼び出しでありAPIサーバーが処理します。 +すべての操作とコンポーネント間の通信、および外部ユーザーのコマンドは、REST API呼び出しでありAPIサーバーが処理します。 その結果、Kubernetesプラットフォーム内のすべてのものは、APIオブジェクトとして扱われ、[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)に対応するエントリーがあります。 @@ -38,30 +38,31 @@ APIのバージョンが異なると、安定性やサポートのレベルも 各レベルの概要は以下の通りです: - Alpha: - - バージョン名に「alpha」が含まれています（例：「v1alpha1」）。 + - バージョン名に`alpha`が含まれています（例：`v1alpha1`）。 + - 組み込みのalpha APIバージョンはデフォルトで無効化されており、使用するためには`kube-apiserver`の設定で明示的に有効にする必要があります。 - バグが含まれている可能性があります。 機能を有効にするとバグが露呈する可能性があります。 - 機能がデフォルトで無効になっている可能性があります。 - - ある機能のサポートは、予告なしにいつでも中止される可能性があります。 + - alpha APIのサポートは、予告なしにいつでも中止される可能性があります。 - 後にリリースされるソフトウェアで、互換性のない方法で予告なく変更される可能性があります。 - バグのリスクが高く、長期的なサポートが得られないため、短期間のテストクラスターのみでの使用を推奨します。 - Beta: - バージョン名には `beta` が含まれています(例：`v2beta3`)。 + - 組み込みのbeta APIバージョンはデフォルトで無効化されており、使用するためには`kube-apiserver`の設定で明示的に有効にする必要があります。 + (**例外として**Kubernetes 1.22以前に導入されたAPIのbetaバージョンはデフォルトで有効化されています) + - 組み込みのbeta APIバージョンは、導入から非推奨となるまでが9ヶ月または3マイナーリリース（どちらかの長い期間）、そして非推奨から削除まで9ヶ月または3マイナーリリース（どちらかの長い期間）の最大存続期間を持ちます。 - ソフトウェアは十分にテストされています。 機能を有効にすることは安全であると考えられています。 - 機能はデフォルトで有効になっています。 - 機能のサポートが打ち切られることはありませんが、詳細は変更される可能性があります。 - - オブジェクトのスキーマやセマンティクスは、その後のベータ版や安定版のリリースで互換性のない方法で変更される可能性があります。 + - オブジェクトのスキーマやセマンティクスは、その後のベータ版や安定版のAPIバージョンで互換性のない方法で変更される可能性があります。 このような場合には、移行手順が提供されます。 - スキーマの変更に伴い、APIオブジェクトの削除、編集、再作成が必要になる場合があります。 - 編集作業は単純ではないかもしれません。 + 後続のbetaまたはstable APIバージョンに適応することはAPIオブジェクトの編集や再作成が必要になる場合があり、単純ではないかもしれません。 移行に伴い、その機能に依存しているアプリケーションのダウンタイムが必要になる場合があります。 - 本番環境での使用は推奨しません。 - 後続のリリース は、互換性のない変更を導入する可能性があります。 - 独立してアップグレード可能な複数のクラスターがある場合、この制限を緩和できる可能性があります。 + 後続のリリースは、互換性のない変更を導入する可能性があります。 + beta APIが非推奨となり提供されなくなった際には、後続のbetaまたはstable APIバージョンに移行するためにbeta APIバージョンを使用する必要があります。 {{< note >}} ベータ版の機能をお試しいただき、ご意見をお寄せください。 @@ -70,7 +71,7 @@ APIのバージョンが異なると、安定性やサポートのレベルも - Stable: - バージョン名は `vX` であり、`X` は整数である。 - - 安定版の機能は、リリースされたソフトウェアの中で、その後の多くのバージョンに登場します。 + - stable APIバージョンはKubernetesのメジャーバージョン内の全てのリリースで利用可能であり、stable APIを削除したKubernetesのメジャーバージョンリビジョンの計画は現在ありません。 ## APIグループ From 8a55837f796dcbfa69b7d8b40eff71ce56202e29 Mon Sep 17 00:00:00 2001 From: Arhell Date: Thu, 9 Mar 2023 00:21:44 +0200 Subject: [PATCH 079/215] [id] Change shell to console for code snippet --- .../configure-pod-container/configure-volume-storage.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md index 2da9cebcdabe3..02d664d530457 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/id/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -41,7 +41,7 @@ yang tetap bertahan, meski Container berakhir dan dimulai ulang. Berikut berkas Hasil keluaran seperti ini: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s ``` @@ -69,7 +69,7 @@ yang tetap bertahan, meski Container berakhir dan dimulai ulang. Berikut berkas Keluarannya mirip seperti ini: - ```shell + ```console USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash @@ -86,7 +86,7 @@ yang tetap bertahan, meski Container berakhir dan dimulai ulang. Berikut berkas 2. Di dalam terminal awal, amati perubahan terhadap Pod Redis. Sampai akhirnya kamu akan melihat hal seperti ini: - ```shell + ```console NAME READY STATUS RESTARTS AGE redis 1/1 Running 0 13s redis 0/1 Completed 0 6m From 0064a0b3f9da167654735492ca28b4c888d523bd Mon Sep 17 00:00:00 2001 From: ziyi-xie <92832323+ziyi-xie@users.noreply.github.com> Date: Thu, 9 Mar 2023 09:47:04 +0900 Subject: [PATCH 080/215] Update content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- .../ja/docs/concepts/scheduling-eviction/assign-pod-node.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 4404abd8762ae..6377b8540836a 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -325,6 +325,12 @@ Podアンチアフィニティを使用する理由は他にもあります。 - 指定されたNodeがPodを収容するためのリソースを持っていない場合、Podの起動は失敗し、OutOfmemoryやOutOfcpuなどの理由が表示されます。 - クラウド環境におけるNode名は、常に予測可能で安定したものではありません。 +{{< note >}} +`nodeName`は、カスタムスケジューラーや、設定済みのスケジューラーをバイパスする必要がある高度なユースケースで使用することを目的としています。 +スケジューラーをバイパスすると、割り当てられたNodeに過剰なPodの配置をしようとした場合には、Podの起動に失敗することがあります。 +[Nodeアフィニティ](#node-affinity)または[`nodeSelector`フィールド](#nodeselector)を使用すれば、スケジューラーをバイパスせずに、特定のNodeにPodを割り当てることができます。 +{{}} + 以下は、`nodeName`フィールドを使用したPod仕様(spec)の例になります: ```yaml From 05d117d5340d2d580cd4aeb5f423aee808f1e78b Mon Sep 17 00:00:00 2001 From: s-kawamura-w664 Date: Wed, 8 Mar 2023 01:07:15 +0000 Subject: [PATCH 081/215] [ja] Remove content/ja/docs/reference/kubectl/overview.md --- .../manage-deployment.md | 2 +- .../api-extension/custom-resources.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 2 +- content/ja/docs/reference/_index.md | 2 +- content/ja/docs/reference/glossary/kubectl.md | 19 + content/ja/docs/reference/kubectl/_index.md | 492 +++++++++++++++++- .../ja/docs/reference/kubectl/cheatsheet.md | 4 +- content/ja/docs/reference/kubectl/overview.md | 485 ----------------- .../setup/learning-environment/minikube.md | 2 +- .../production-environment/tools/kops.md | 2 +- .../tools/kubeadm/create-cluster-kubeadm.md | 2 +- .../windows/user-guide-windows-containers.md | 2 +- .../ja/docs/tasks/tools/install-kubectl.md | 2 +- content/ja/docs/tutorials/hello-minikube.md | 2 +- 14 files changed, 522 insertions(+), 498 deletions(-) create mode 100644 content/ja/docs/reference/glossary/kubectl.md delete mode 100644 content/ja/docs/reference/kubectl/overview.md diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md index 35def1de1269e..280dda204660a 100644 --- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md @@ -157,7 +157,7 @@ deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created ``` -`kubectl`についてさらに知りたい場合は、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。 +`kubectl`についてさらに知りたい場合は、[コマンドラインツール(kubectl)](/ja/docs/reference/kubectl/)を参照してください。 ## ラベルを有効に使う diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 9fea0905c6ec9..1679d2929f0d0 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -18,7 +18,7 @@ weight: 10 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。 -カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 +カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 ## カスタムコントローラー diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 5b6388a306adf..5f9f03bcdf30d 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -18,7 +18,7 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 -ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。 +ほとんどの操作は、APIを使用している[kubectl](/ja/docs/reference/kubectl/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。 RESTコールを利用して直接APIにアクセスすることも可能です。 Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。 diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index cafca8fe448a6..3940d23f429eb 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -30,7 +30,7 @@ content_type: concept ## CLIリファレンス -* [kubectl](/ja/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 +* [kubectl](/ja/docs/reference/kubectl/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 * [kubeadm](/ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 diff --git a/content/ja/docs/reference/glossary/kubectl.md b/content/ja/docs/reference/glossary/kubectl.md new file mode 100644 index 0000000000000..ff7796060bd61 --- /dev/null +++ b/content/ja/docs/reference/glossary/kubectl.md @@ -0,0 +1,19 @@ +--- +title: Kubectl +id: kubectl +date: 2018-04-12 +full_link: /docs/reference/kubectl/ +short_description: > + Kubernetesクラスターと通信するためのコマンドラインツールです。 + +aka: +- kubectl +tags: +- tool +- fundamental +--- +Kubernetes APIを使用してKubernetesクラスターの{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}と通信するためのコマンドラインツールです。 + + + +Kubernetesオブジェクトの作成、検査、更新、削除には `kubectl` を使用することができます。 diff --git a/content/ja/docs/reference/kubectl/_index.md b/content/ja/docs/reference/kubectl/_index.md index 6738659218c18..bceb521c2fa9f 100644 --- a/content/ja/docs/reference/kubectl/_index.md +++ b/content/ja/docs/reference/kubectl/_index.md @@ -1,5 +1,495 @@ --- -title: "kubectl CLI" +title: コマンドラインツール(kubectl) +content_type: reference weight: 110 +no_list: true +card: + name: reference + weight: 20 --- + +{{< glossary_definition prepend="Kubernetesが提供する、" term_id="kubectl" length="short" >}} + +このツールの名前は、`kubectl` です。 + +`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。 + +この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。 + +インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。クイックガイドは、[cheat sheet](/docs/reference/kubectl/cheatsheet/) をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/) でKubernetesの同等のコマンドを説明しています。 + + + +## 構文 + +ターミナルウィンドウから`kubectl`コマンドを実行するには、以下の構文を使用します。 + +```shell +kubectl [command] [TYPE] [NAME] [flags] +``` + +ここで、`command`、`TYPE`、`NAME`、`flags`は、以下を表します。 + +* `command`: 1つ以上のリソースに対して実行したい操作を指定します。例えば、`create`、`get`、`describe`、`delete`です。 + +* `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。 + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + +* `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。 + + 複数のリソースに対して操作を行う場合は、各リソースをタイプと名前で指定するか、1つまたは複数のファイルを指定することができます。 + + * リソースをタイプと名前で指定する場合 + + * タイプがすべて同じとき、リソースをグループ化するには`TYPE1 name1 name2 name<#>`とします。
+ 例: `kubectl get pod example-pod1 example-pod2` + + * 複数のリソースタイプを個別に指定するには、`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`とします。
+ 例: `kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。 + + * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。
+ 例: `kubectl get pod -f ./pod.yaml` + +* `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。
+ +{{< caution >}} +コマンドラインから指定したフラグは、デフォルト値および対応する任意の環境変数を上書きします。 +{{< /caution >}} + +ヘルプが必要な場合は、ターミナルウィンドウから`kubectl help`を実行してください。 + +## 操作 + +以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。 + +操作                 | 構文 | 説明 +-------------------- | -------------------- | -------------------- +`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。 +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 1つ以上のリソースのアノテーションを、追加または更新します。 +`api-resources` | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。 +`api-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。 +`apply` | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。 +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。 +`auth` | `kubectl auth [flags] [options]` | 認可を検査します。 +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。 +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。 +`cluster-info` | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。 +`completion` | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。 +`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。 +`convert` | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。 +`cordon` | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。 +`cp` | `kubectl cp [options]` | コンテナとの間でファイルやディレクトリをコピーします。 +`create` | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。 +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。 +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 1つ以上のリソースの詳細な状態を表示します。 +`diff` | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。 +`drain` | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。 +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。 +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。 +`explain` | `kubectl explain [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。 +`expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。 +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 1つ以上のリソースを表示します。 +`kustomize` | `kubectl kustomize [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。 +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 1つ以上のリソースのラベルを、追加または更新します。 +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。 +`options` | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。 +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。 +`plugin` | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。 +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。 +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。 +`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。 +`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。 +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 指定したイメージを、クラスタ上で実行します。 +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 指定したReplicationControllerのサイズを更新します。 +`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。 +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。 +`top` | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。 +`uncordon` | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。 +`version` | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。 +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。 + +コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。 + +## リソースタイプ {#resource-types} + +以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。 + +(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。) + +| リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 | +|---|---|---|---|---| +| `bindings` | | | true | Binding| +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true| ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `csidrivers` | | storage.k8s.io | false | CSIDriver | +| `csinodes` | | storage.k8s.io | false | CSINode | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | + +## 出力オプション + +ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。 + +### 出力のフォーマット + +すべての`kubectl`コマンドのデフォルトの出力フォーマットは、人間が読みやすいプレーンテキスト形式です。特定のフォーマットで、詳細をターミナルウィンドウに出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグのいずれかを追加します。 + +#### 構文 + +```shell +kubectl [command] [TYPE] [NAME] -o +``` + +`kubectl`の操作に応じて、以下の出力フォーマットがサポートされています。 + +出力フォーマット | 説明 +--------------| ----------- +`-o custom-columns=` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。 +`-o custom-columns-file=` | ``ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。 +`-o json` | JSON形式のAPIオブジェクトを出力します。 +`-o jsonpath=