From acd4b56d5a10e50b65beb3edd12164e9181d5d35 Mon Sep 17 00:00:00 2001 From: cyberblack28 Date: Tue, 11 Aug 2020 01:18:59 +0900 Subject: [PATCH 01/11] 20200811 Translate before Observability --- .../windows/user-guide-windows-containers.md | 49 ++++++++++--------- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index ee1ed7b9f1..63a1b4633d 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,30 +1,30 @@ --- -title: Guide for scheduling Windows containers in Kubernetes +title: KubernetesでWindowsコンテナーをスケジュールするためのガイド content_type: concept weight: 75 --- -Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes. +Windowsアプリケーションは、多くの組織で実行されるサービスとアプリケーションの大部分を占めます。このガイドでは、KubernetesでWindowsコンテナを構成してデプロイする手順について説明します。 -## Objectives +## 目的 -* Configure an example deployment to run Windows containers on the Windows node -* (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA) +* WindowsノードでWindowsコンテナを実行するサンプルのDeploymentを構成します +* (オプション)Group Managed Service Accounts(GMSA)を使用してPodのActive Directory IDを構成します -## Before you begin +## 始める前に -* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/) -* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided simply to jumpstart your experience with Windows containers. +* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)を含むKubernetesクラスターを作成します +* Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。 -## Getting Started: Deploying a Windows container +## はじめに:Windowsコンテナーのデプロイ -To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below: +WindowsコンテナをKubernetesにデプロイするには、最初にサンプルアプリケーションを作成する必要があります。以下のYAMLファイルの例では、簡単なウェブサーバーアプリケーションを作成しています。以下の内容で「win-webserver.yaml」という名前のサービススペックを作成します。: ```yaml apiVersion: v1 @@ -35,7 +35,7 @@ metadata: app: win-webserver spec: ports: - # the port that this service should serve on + # このサービスが提供するポート - port: 80 targetPort: 80 selector: @@ -71,37 +71,38 @@ spec: ``` {{< note >}} -Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service. +ポートマッピングもサポートされていますが、この例では簡単にするために、コンテナポート80がサービスに直接公開されています。 {{< /note >}} -1. Check that all nodes are healthy: +1. すべてのノードが正常であることを確認します。: ```bash kubectl get nodes ``` -1. Deploy the service and watch for pod updates: +1. Serviceをデプロイして、Podの更新を確認します。: ```bash kubectl apply -f win-webserver.yaml kubectl get pods -o wide -w ``` - When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C. + Serviceが正しくデプロイされると、両方のPodがReadyとして表示されます。watch状態のコマンドを終了するには、Ctrl + Cを押します。 -1. Check that the deployment succeeded. To verify: +1. デプロイが成功したことを確認します。検証するために行うこと: - * Two containers per pod on the Windows node, use `docker ps` - * Two pods listed from the Linux master, use `kubectl get pods` - * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response - * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec - * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods - * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services) + * WindowsノードのPodごとの2つのコンテナに`docker ps`します + * Linuxマスターからリストされた2つのPodに`kubectl get pods`します + * ネットワークを介したノードとPod間通信、LinuxマスターからのPod IPのポート80に向けて`curl`して、ウェブサーバーの応答をチェックします + * docker execまたはkubectl execを使用したPod間通信、Pod間(および複数のWindowsノードがある場合はホスト間)へのpingします + * ServiceからPodへの通信、Linuxマスターおよび個々のPodからの仮想Service IP(`kubectl get services`で表示される)に`curl`します + * サービスディスカバリ、Kuberntesの[default DNS suffix](/ja/docs/concepts/services-networking/dns-pod-service/#services)と共にService名に`curl`します * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster - * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec + * インバウンド接続、Linuxマスターまたはクラスター外のマシンからNodePortに`curl`します + * アウトバウンド接続、kubectl execを使用したPod内からの外部IPに`curl`します {{< note >}} -Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs. +今のところ、Windowsネットワークスタックのプラットフォーム制限のため、Windowsコンテナホストは、ホストされているサービスのIPにアクセスできません。Service IPにアクセスできるのは、Windows Podだけです。 {{< /note >}} ## Observability From b3177bcd52f4d93587b2dca9b55801488d19f60b Mon Sep 17 00:00:00 2001 From: cyberblack28 Date: Thu, 13 Aug 2020 23:51:18 +0900 Subject: [PATCH 02/11] 20200813 Translate Complete --- .../windows/user-guide-windows-containers.md | 63 +++++++++---------- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 63a1b4633d..253f5a8874 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,5 +1,5 @@ --- -title: KubernetesでWindowsコンテナーをスケジュールするためのガイド +title: KubernetesでWindowsコンテナをスケジュールするためのガイド content_type: concept weight: 75 --- @@ -22,9 +22,9 @@ Windowsアプリケーションは、多くの組織で実行されるサービ * [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)を含むKubernetesクラスターを作成します * Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。 -## はじめに:Windowsコンテナーのデプロイ +## はじめに:Windowsコンテナのデプロイ -WindowsコンテナをKubernetesにデプロイするには、最初にサンプルアプリケーションを作成する必要があります。以下のYAMLファイルの例では、簡単なウェブサーバーアプリケーションを作成しています。以下の内容で「win-webserver.yaml」という名前のサービススペックを作成します。: +WindowsコンテナをKubernetesにデプロイするには、最初にサンプルアプリケーションを作成する必要があります。以下のYAMLファイルの例では、簡単なウェブサーバーアプリケーションを作成しています。以下の内容で`win-webserver.yaml`という名前のサービススペックを作成します。: ```yaml apiVersion: v1 @@ -105,40 +105,40 @@ spec: 今のところ、Windowsネットワークスタックのプラットフォーム制限のため、Windowsコンテナホストは、ホストされているサービスのIPにアクセスできません。Service IPにアクセスできるのは、Windows Podだけです。 {{< /note >}} -## Observability +## 可観測性 -### Capturing logs from workloads +### ワークロードからのログキャプチャ -Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs `. +ログは可観測性の重要な要素です。これにより、ユーザーはワークロードの運用面に関する洞察を得ることができ、問題のトラブルシューティングの主要な要素になります。WindowsコンテナとWindowsコンテナ内のワークロードの動作はLinuxコンテナとは異なるため、ユーザーはログの収集に苦労し、運用の可視性が制限されていました。たとえば、Windowsワークロードは通常、ETW(Windowsのイベントトレース)にログを記録するか、アプリケーションイベントログにエントリをプッシュするように構成されます。Microsoftのオープンソースツールである[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)は、Windowsコンテナ内の構成されたログソースを監視するための推奨方法です。LogMonitorは、イベントログ、ETWプロバイダー、カスタムアプリケーションログのモニタリングをサポートしており、それらをSTDOUTにパイプして、`kubectl logs `で使用できます。 -Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. +LogMonitor GitHubページの指示に従って、バイナリと構成ファイルをすべてのコンテナにコピーして、LogMonitorがログをSTDOUTにプッシュするために必要なエントリポイントを追加します。 -## Using configurable Container usernames +## 構成可能なコンテナのユーザー名の使用 -Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). +Kubernetes v1.16以降、Windowsコンテナは、イメージのデフォルトとは異なるユーザー名でエントリポイントとプロセスを実行するように構成できます。これが達成される方法は、Linuxコンテナで行われる方法とは少し異なります。詳しくは[こちら](/docs/tasks/configure-pod-container/configure-runasusername/). -## Managing Workload Identity with Group Managed Service Accounts +## Group Managed Service AccountsによるワークロードIDの管理 -Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). +Kubernetes v1.14以降、Windowsコンテナワークロードは、Group Managed Service Accounts(GMSA)を使用するように構成できます。Group Managed Service Accountsは、自動パスワード管理、簡略化されたサービスプリンシパル名（SPN）管理、および複数のサーバー間で他の管理者に管理を委任する機能を提供する特定の種類のActive Directoryアカウントです。GMSAで構成されたコンテナは、GMSAで構成されたIDを保持しながら、外部Active Directoryドメインリソースにアクセスできます。Windowsコンテナ用のGMSAの構成と使用の詳細は[こちら](/docs/tasks/configure-pod-container/configure-gmsa/)。 -## Taints and Tolerations +## TaintsとTolerations -Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads. +今日のユーザーは、LinuxとWindowsのワークロードをそれぞれのOS固有のノードで維持するために、Taintsとノードセレクターのいくつかの組み合わせを使用する必要があります。これはおそらくWindowsユーザーにのみ負担をかけます。推奨されるアプローチの概要を以下に示します。主な目標の1つは、このアプローチによって既存のLinuxワークロードの互換性が損なわれないようにすることです。 -### Ensuring OS-specific workloads land on the appropriate container host +### OS固有のワークロードが適切なコンテナホストに確実に到達するようにする -Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels: +ユーザーは、TaintsとTolerationsを使用して、Windowsコンテナを適切なホストでスケジュールできるようにすることができます。現在、すべてのKubernetesノードには次のデフォルトラベルがあります。: * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. +Podの仕様で`"kubernetes.io/os": windows`のようなnodeSelectorが指定されていない場合、PodをWindowsまたはLinuxの任意のホストでスケジュールすることができます。WindowsコンテナはWindowsでのみ実行でき、LinuxコンテナはLinuxでのみ実行できるため、これは問題になる可能性があります。ベストプラクティスは、nodeSelectorを使用することです。 -However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only. +ただし、多くの場合、ユーザーには既存の多数のLinuxコンテナのdepolyment、およびコミュニティHelmチャートのような既成構成のエコシステムやOperatorのようなプログラム的にPodを生成するケースがあることを理解しています。このような状況では、nodeSelectorsを追加するための構成変更をためらう可能性があります。代替策は、Taintsを使用することです。kubeletは登録中にTaintsを設定できるため、Windowsだけで実行する時に自動的にTaintを追加するように簡単に変更できます。 -For example: `--register-with-taints='os=windows:NoSchedule'` +例:`--register-with-taints='os=windows:NoSchedule'` -By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration. +すべてのWindowsノードにTaintを追加することにより、それらには何もスケジュールされません（既存のLinuxPodを含む）。Windows PodがWindowsノードでスケジュールされるためには、nodeSelectorがWindowsを選択することと、適切にマッチするTolerationが必要です。 ```yaml nodeSelector: @@ -151,28 +151,27 @@ tolerations: effect: "NoSchedule" ``` -### Handling multiple Windows versions in the same cluster +### 同じクラスター内の複数Windowsバージョンの管理 -The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows -Server versions in the same cluster, then you should set additional node labels and nodeSelectors. +各Podで使用されるWindows Serverのバージョンは、ノードのバージョンと一致している必要があります。 +同じクラスター内で複数のWindows Serverバージョンを使用したい場合は、追加のノードラベルとnodeSelectorsを設定する必要があります。 -Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes. +Kubernetes 1.17では、これを簡単するために新しいラベル`node.kubernetes.io/windows-build`が自動的に追加されます。古いバージョンを実行している場合は、このラベルをWindowsノードに手動で追加することをお勧めします。 -This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version. +このラベルは、互換性のために一致する必要があるWindowsのメジャー、マイナー、およびビルド番号を反映しています。以下は、Windows Serverの各バージョンで現在使用されている値です。 -| Product Name | Build Number(s) | +| 製品番号 　　 | ビルド番号 | |--------------------------------------|------------------------| | Windows Server 2019 | 10.0.17763 | | Windows Server version 1809 | 10.0.17763 | | Windows Server version 1903 | 10.0.18362 | -### Simplifying with RuntimeClass +### RuntimeClassによる簡素化 -[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. +[RuntimeClass]は、TaintsとTolerationsを使用するプロセスを簡略化するために使用できます。クラスター管理者は、これらのTaintsとTolerationsをカプセル化するために使用する`RuntimeClass`オブジェクトを作成できます。 - -1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version. +1. このファイルを`runtimeClasses.yml`に保存します。これには、Windows OS、アーキテクチャ、およびバージョンに適切な`nodeSelector`が含まれています。 ```yaml apiVersion: node.k8s.io/v1beta1 @@ -192,10 +191,10 @@ scheduling: value: "windows" ``` -1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator -1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs +1. クラスター管理者として使用する`kubectl create -f runtimeClasses.yml`を実行します +1. Podの仕様に応じて`runtimeClassName: windows-2019`を追加します -For example: +例: ```yaml apiVersion: apps/v1 From 8b2772760abd274bf66b5f7305a16a4f9d758702 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 16 Aug 2020 02:45:11 +0900 Subject: [PATCH 03/11] Copy tasks/configure-pod-container/assign-pods-nodes-using-node-affinity from en/ directory. --- .../assign-pods-nodes-using-node-affinity.md | 122 ++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md new file mode 100644 index 0000000000..8306724c1d --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -0,0 +1,122 @@ +--- +title: Assign Pods to Nodes using Node Affinity +min-kubernetes-server-version: v1.10 +content_type: task +weight: 120 +--- + + +This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a +Kubernetes cluster. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Add a label to a node + +1. List the nodes in your cluster, along with their labels: + + ```shell + kubectl get nodes --show-labels + ``` + The output is similar to this: + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. Chose one of your nodes, and add a label to it: + + ```shell + kubectl label nodes disktype=ssd + ``` + where `` is the name of your chosen node. + +1. Verify that your chosen node has a `disktype=ssd` label: + + ```shell + kubectl get nodes --show-labels + ``` + + The output is similar to this: + + ``` + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + In the preceding output, you can see that the `worker0` node has a + `disktype=ssd` label. + +## Schedule a Pod using required node affinity + +This manifest describes a Pod that has a `requiredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. +This means that the pod will get scheduled only on a node that has a `disktype=ssd` label. + +{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}} + +1. Apply the manifest to create a Pod that is scheduled onto your + chosen node: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml + ``` + +1. Verify that the pod is running on your chosen node: + + ```shell + kubectl get pods --output=wide + ``` + + The output is similar to this: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## Schedule a Pod using preferred node affinity + +This manifest describes a Pod that has a `preferredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. +This means that the pod will prefer a node that has a `disktype=ssd` label. + +{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}} + +1. Apply the manifest to create a Pod that is scheduled onto your + chosen node: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml + ``` + +1. Verify that the pod is running on your chosen node: + + ```shell + kubectl get pods --output=wide + ``` + + The output is similar to this: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + + + +## {{% heading "whatsnext" %}} + +Learn more about +[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). + From 39d1db81e1e98b6eb5b8fc3e949823e8c4c979f9 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 16 Aug 2020 04:57:31 +0900 Subject: [PATCH 04/11] Copy Pod resource files. --- .../pods/pod-nginx-preferred-affinity.yaml | 19 +++++++++++++++++++ .../pods/pod-nginx-required-affinity.yaml | 18 ++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 content/ja/examples/pods/pod-nginx-preferred-affinity.yaml create mode 100644 content/ja/examples/pods/pod-nginx-required-affinity.yaml diff --git a/content/ja/examples/pods/pod-nginx-preferred-affinity.yaml b/content/ja/examples/pods/pod-nginx-preferred-affinity.yaml new file mode 100644 index 0000000000..7cc3aa4db9 --- /dev/null +++ b/content/ja/examples/pods/pod-nginx-preferred-affinity.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ja/examples/pods/pod-nginx-required-affinity.yaml b/content/ja/examples/pods/pod-nginx-required-affinity.yaml new file mode 100644 index 0000000000..2c40672384 --- /dev/null +++ b/content/ja/examples/pods/pod-nginx-required-affinity.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent From 006a5825e907ade515da79a09da1094b612442dd Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 16 Aug 2020 03:08:17 +0900 Subject: [PATCH 05/11] Translate tasks/configure-pod-container/assign-pods-nodes-using-node-affinity into Japanese. --- .../assign-pods-nodes-using-node-affinity.md | 53 ++++++++----------- 1 file changed, 23 insertions(+), 30 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md index 8306724c1d..5154669ed5 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -1,13 +1,12 @@ --- -title: Assign Pods to Nodes using Node Affinity +title: Node Affinityを利用してPodをノードに割り当てる min-kubernetes-server-version: v1.10 content_type: task weight: 120 --- -This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a -Kubernetes cluster. +このページでは、Node Affinityを利用して、PodをKubernetesクラスター内の特定のノードに割り当てる方法を説明します。 ## {{% heading "prerequisites" %}} @@ -19,14 +18,15 @@ Kubernetes cluster. -## Add a label to a node +## ノードにラベルを追加する -1. List the nodes in your cluster, along with their labels: +1. クラスター内のノードを一覧表示して、ラベルを確認します。 ```shell kubectl get nodes --show-labels ``` - The output is similar to this: + + 出力は次のようになります。 ```shell NAME STATUS ROLES AGE VERSION LABELS @@ -34,20 +34,21 @@ Kubernetes cluster. worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 ``` -1. Chose one of your nodes, and add a label to it: +1. ノードを選択して、ラベルを追加します。 ```shell kubectl label nodes disktype=ssd ``` - where `` is the name of your chosen node. -1. Verify that your chosen node has a `disktype=ssd` label: + ここで、``は選択したノードの名前で置換します。 + +1. 選択したノードに`disktype=ssd`ラベルがあることを確認します。 ```shell kubectl get nodes --show-labels ``` - The output is similar to this: + 出力は次のようになります。 ``` NAME STATUS ROLES AGE VERSION LABELS @@ -56,67 +57,59 @@ Kubernetes cluster. worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 ``` - In the preceding output, you can see that the `worker0` node has a - `disktype=ssd` label. + この出力を見ると、`worker0`ノードに`disktype=ssd`というラベルが追加されたことがわかります。 -## Schedule a Pod using required node affinity +## required node affinityを使用してPodをスケジューリングする -This manifest describes a Pod that has a `requiredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. -This means that the pod will get scheduled only on a node that has a `disktype=ssd` label. +以下に示すマニフェストには、`requiredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードにだけスケジューリングされるようになります。 {{< codenew file="pods/pod-nginx-required-affinity.yaml" >}} -1. Apply the manifest to create a Pod that is scheduled onto your - chosen node: +1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。 ```shell kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml ``` -1. Verify that the pod is running on your chosen node: +1. Podが選択したノード上で実行されていることを確認します。 ```shell kubectl get pods --output=wide ``` - The output is similar to this: + 出力は次のようになります。 ``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` -## Schedule a Pod using preferred node affinity +## preferred node affinityを使用してPodをスケジューリングする -This manifest describes a Pod that has a `preferredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. -This means that the pod will prefer a node that has a `disktype=ssd` label. +以下に示すマニフェストには、`preferredDuringSchedulingIgnoredDuringExecution`に`disktype: ssd`というnode affinityを使用したPodが書かれています。このように書くと、Podは`disktype=ssd`というラベルを持つノードに優先的にスケジューリングされるようになります。 {{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}} -1. Apply the manifest to create a Pod that is scheduled onto your - chosen node: +1. マニフェストを適用して、選択したノード上にスケジューリングされるPodを作成します。 ```shell kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml ``` -1. Verify that the pod is running on your chosen node: +1. Podが選択したノード上で実行されていることを確認します。 ```shell kubectl get pods --output=wide ``` - The output is similar to this: + 出力は次のようになります。 ``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` - - ## {{% heading "whatsnext" %}} -Learn more about -[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). +[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。 From f28cae995fa2b98d6e1a42335ede32cfc2e3f045 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 18 Aug 2020 10:10:52 +0900 Subject: [PATCH 06/11] Copy tasks/configure-pod-container/static-pod.md and glossary word files from en/ directory. --- content/ja/docs/reference/glossary/docker.md | 17 ++ .../ja/docs/reference/glossary/mirror-pod.md | 21 ++ .../configure-pod-container/static-pod.md | 240 ++++++++++++++++++ 3 files changed, 278 insertions(+) create mode 100755 content/ja/docs/reference/glossary/docker.md create mode 100755 content/ja/docs/reference/glossary/mirror-pod.md create mode 100644 content/ja/docs/tasks/configure-pod-container/static-pod.md diff --git a/content/ja/docs/reference/glossary/docker.md b/content/ja/docs/reference/glossary/docker.md new file mode 100755 index 0000000000..fee6a7d838 --- /dev/null +++ b/content/ja/docs/reference/glossary/docker.md @@ -0,0 +1,17 @@ +--- +title: Docker +id: docker +date: 2018-04-12 +full_link: https://docs.docker.com/engine/ +short_description: > + Docker is a software technology providing operating-system-level virtualization also known as containers. + +aka: +tags: +- fundamental +--- +Docker (specifically, Docker Engine) is a software technology providing operating-system-level virtualization also known as {{< glossary_tooltip text="containers" term_id="container" >}}. + + + +Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs). diff --git a/content/ja/docs/reference/glossary/mirror-pod.md b/content/ja/docs/reference/glossary/mirror-pod.md new file mode 100755 index 0000000000..c925e4d672 --- /dev/null +++ b/content/ja/docs/reference/glossary/mirror-pod.md @@ -0,0 +1,21 @@ +--- +title: Mirror Pod +id: mirror-pod +date: 2019-08-06 +short_description: > + An object in the API server that tracks a static pod on a kubelet. + +aka: +tags: +- fundamental +--- + A {{< glossary_tooltip text="pod" term_id="pod" >}} object that a kubelet uses + to represent a {{< glossary_tooltip text="static pod" term_id="static-pod" >}} + + + +When the kubelet finds a static pod in its configuration, it automatically tries to +create a Pod object on the Kubernetes API server for it. This means that the pod +will be visible on the API server, but cannot be controlled from there. + +(For example, removing a mirror pod will not stop the kubelet daemon from running it). diff --git a/content/ja/docs/tasks/configure-pod-container/static-pod.md b/content/ja/docs/tasks/configure-pod-container/static-pod.md new file mode 100644 index 0000000000..cf31d822d6 --- /dev/null +++ b/content/ja/docs/tasks/configure-pod-container/static-pod.md @@ -0,0 +1,240 @@ +--- +reviewers: +- jsafrane +title: Create static Pods +weight: 170 +content_type: task +--- + + + + +*Static Pods* are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Unlike Pods that are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}); +instead, the kubelet watches each static Pod (and restarts it if it fails). + +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. + +{{< note >}} +If you are running clustered Kubernetes and are using static +Pods to run a Pod on every node, you should probably be using a +{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} +instead. +{{< /note >}} + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods, +and that your nodes are running the Fedora operating system. +Instructions for other distributions or Kubernetes installations may vary. + + + + + + + +## Create a static pod {#static-pod-creation} + +You can configure a static Pod with either a [file system hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#configuration-files) or a [web hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http). + +### Filesystem-hosted static Pod manifest {#configuration-files} + +Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: ` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there. +Note that the kubelet will ignore files starting with dots when scanning the specified directory. + +For example, this is how to start a simple web server as a static Pod: + +1. Choose a node where you want to run the static Pod. In this example, it's `my-node1`. + + ```shell + ssh my-node1 + ``` + +2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`: + + ```shell + # Run this command on the node where kubelet is running + mkdir /etc/kubelet.d/ + cat </etc/kubelet.d/static-web.yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + EOF + ``` + +3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line: + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + or add the `staticPodPath: ` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file). + +4. Restart the kubelet. On Fedora, you would run: + + ```shell + # Run this command on the node where the kubelet is running + systemctl restart kubelet + ``` + +### Web-hosted static pod manifest {#pods-created-via-http} + +Kubelet periodically downloads a file specified by `--manifest-url=` argument +and interprets it as a JSON/YAML file that contains Pod definitions. +Similar to how [filesystem-hosted manifests](#configuration-files) work, the kubelet +refetches the manifest on a schedule. If there are changes to the list of static +Pods, the kubelet applies them. + +To use this approach: + +1. Create a YAML file and store it on a web server so that you can pass the URL of that file to the kubelet. + + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + ``` + +2. Configure the kubelet on your selected node to use this web manifest by running it with `--manifest-url=`. On Fedora, edit `/etc/kubernetes/kubelet` to include this line: + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" + ``` + +3. Restart the kubelet. On Fedora, you would run: + + ```shell + # Run this command on the node where the kubelet is running + systemctl restart kubelet + ``` + +## Observe static pod behavior {#behavior-of-static-pods} + +When the kubelet starts, it automatically starts all defined static Pods. As you have +defined a static Pod and restarted the kubelet, the new static Pod should +already be running. + +You can view running containers (including static Pods) by running (on the node): +```shell +# Run this command on the node where the kubelet is running +docker ps +``` + +The output might be something like: + +``` +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +``` + +You can see the mirror Pod on the API server: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m +``` + +{{< note >}} +Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See +[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/). +{{< /note >}} + + +{{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are +propagated into the mirror Pod. You can use those labels as normal via +{{< glossary_tooltip term_id="selector" text="selectors" >}}, etc. + +If you try to use `kubectl` to delete the mirror Pod from the API server, +the kubelet _doesn't_ remove the static Pod: + +```shell +kubectl delete pod static-web-my-node1 +``` +``` +pod "static-web-my-node1" deleted +``` +You can see that the Pod is still running: +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s +``` + +Back on your node where the kubelet is running, you can try to stop the Docker +container manually. +You'll see that, after a time, the kubelet will notice and will restart the Pod +automatically: + +```shell +# Run these commands on the node where the kubelet is running +docker stop f6d05272b57e # replace with the ID of your container +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +``` + +## Dynamic addition and removal of static pods + +The running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes Pods as files appear/disappear in this directory. + +```shell +# This assumes you are using filesystem-hosted static Pod configuration +# Run these commands on the node where the kubelet is running +# +mv /etc/kubelet.d/static-web.yaml /tmp +sleep 20 +docker ps +# You see that no nginx container is running +mv /tmp/static-web.yaml /etc/kubelet.d/ +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +``` + + From 2803a7bd9fac808f3bc206d0e62eddfeea2d5a4b Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 18 Aug 2020 10:01:42 +0900 Subject: [PATCH 07/11] Translate "docker", "mirror-pod", and "label" in the glossary and modify "selector". --- content/ja/docs/reference/glossary/docker.md | 6 +++--- content/ja/docs/reference/glossary/label.md | 17 +++++++++++++++++ .../ja/docs/reference/glossary/mirror-pod.md | 13 +++++-------- content/ja/docs/reference/glossary/selector.md | 4 ++-- 4 files changed, 27 insertions(+), 13 deletions(-) create mode 100755 content/ja/docs/reference/glossary/label.md diff --git a/content/ja/docs/reference/glossary/docker.md b/content/ja/docs/reference/glossary/docker.md index fee6a7d838..3f839679d2 100755 --- a/content/ja/docs/reference/glossary/docker.md +++ b/content/ja/docs/reference/glossary/docker.md @@ -4,14 +4,14 @@ id: docker date: 2018-04-12 full_link: https://docs.docker.com/engine/ short_description: > - Docker is a software technology providing operating-system-level virtualization also known as containers. + Dockerは、コンテナとして知られる、オペレーティングシステムレベルでの仮想化を提供するソフトウェア技術です。 aka: tags: - fundamental --- -Docker (specifically, Docker Engine) is a software technology providing operating-system-level virtualization also known as {{< glossary_tooltip text="containers" term_id="container" >}}. +Docker(正確にはDocker Engine)は、{{< glossary_tooltip text="コンテナ" term_id="container" >}}としても知られる、オペレーティングシステムレベルでの仮想化を提供するソフトウェア技術です。 -Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs). +Dockerは、croupsやカーネル名前空間などのLinuxカーネルのリソースの隔離機能、OverlayFSなどの統合能力のあるファイルシステム、独立したコンテナを単一のLinuxインスタンス内で実行可能にするその他の機能などを利用して、マシンレベルでの仮想マシン(VM)の起動にかかるオーバーヘッドを回避します。 diff --git a/content/ja/docs/reference/glossary/label.md b/content/ja/docs/reference/glossary/label.md new file mode 100755 index 0000000000..fa770ac291 --- /dev/null +++ b/content/ja/docs/reference/glossary/label.md @@ -0,0 +1,17 @@ +--- +title: ラベル +id: label +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels +short_description: > + ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 + +aka: +tags: +- fundamental +--- + ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 + + + +ラベルは、{{< glossary_tooltip text="Pod" term_id="pod" >}}などのオブジェクトに付与されるキーと値のペアです。オブジェクトのサブセットを組織化したり選択したりするために使われます。 diff --git a/content/ja/docs/reference/glossary/mirror-pod.md b/content/ja/docs/reference/glossary/mirror-pod.md index c925e4d672..7f6c1ed5c8 100755 --- a/content/ja/docs/reference/glossary/mirror-pod.md +++ b/content/ja/docs/reference/glossary/mirror-pod.md @@ -1,21 +1,18 @@ --- -title: Mirror Pod +title: ミラーPod id: mirror-pod date: 2019-08-06 short_description: > - An object in the API server that tracks a static pod on a kubelet. + kubelet上のstatic Podを追跡するAPIサーバー内のオブジェクトです。 aka: tags: - fundamental --- - A {{< glossary_tooltip text="pod" term_id="pod" >}} object that a kubelet uses - to represent a {{< glossary_tooltip text="static pod" term_id="static-pod" >}} +kubeletが{{< glossary_tooltip text="static Pod" term_id="static-pod" >}}を代表するために使用する{{< glossary_tooltip text="Pod" term_id="pod" >}}オブジェクトです。 -When the kubelet finds a static pod in its configuration, it automatically tries to -create a Pod object on the Kubernetes API server for it. This means that the pod -will be visible on the API server, but cannot be controlled from there. +kubeletが設定の中にstatic Podを発見すると、static Podに対応するPodオブジェクトをKubernetes APIサーバー上に自動的に作成しようとします。つまり、APIサーバーからはPodが見えていますが、制御まではできないということです。 -(For example, removing a mirror pod will not stop the kubelet daemon from running it). +(たとえば、ミラーPodを削除しても、kubeletデーモンが対応するPodの実行を停止することはありません。) diff --git a/content/ja/docs/reference/glossary/selector.md b/content/ja/docs/reference/glossary/selector.md index 24d6bcdf53..a4fc039e1e 100755 --- a/content/ja/docs/reference/glossary/selector.md +++ b/content/ja/docs/reference/glossary/selector.md @@ -4,13 +4,13 @@ id: selector date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels/ short_description: > - ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。 + セレクターを利用すると、ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。 aka: tags: - fundamental --- - ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。 + セレクターを利用すると、ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。 From 4bd57c70429969baae487c1d4f8e323ebc56941d Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 16 Aug 2020 20:30:16 +0900 Subject: [PATCH 08/11] Translate tasks/configure-pod-container/static-pod into Japanese. --- .../configure-pod-container/static-pod.md | 126 +++++++----------- 1 file changed, 46 insertions(+), 80 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/static-pod.md b/content/ja/docs/tasks/configure-pod-container/static-pod.md index cf31d822d6..917927c8e0 100644 --- a/content/ja/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/static-pod.md @@ -1,7 +1,5 @@ --- -reviewers: -- jsafrane -title: Create static Pods +title: static Podを作成する weight: 170 content_type: task --- @@ -9,65 +7,44 @@ content_type: task -*Static Pods* are managed directly by the kubelet daemon on a specific node, -without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} -observing them. -Unlike Pods that are managed by the control plane (for example, a -{{< glossary_tooltip text="Deployment" term_id="deployment" >}}); -instead, the kubelet watches each static Pod (and restarts it if it fails). +*Static Pod*とは、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}が監視せず、特定のノード上のkubeletデーモンによって直接管理されるPodです。コントロールプレーンに管理されるPod(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}}など)とは異なり、kubeletがそれぞれのstatic Podを監視(および障害時には再起動)します。 -Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +Static Podは、常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。 -The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} -on the Kubernetes API server for each static Pod. -This means that the Pods running on a node are visible on the API server, -but cannot be controlled from there. +kubeletは、各static Podに対して、自動的にKubernetes APIサーバー上に{{< glossary_tooltip text="ミラーPod" term_id="mirror-pod" >}}の作成を試みます。つまり、ノード上で実行中のPodはAPIサーバーから検出されますが、APIサーバー自身から制御されることはないということです。 {{< note >}} -If you are running clustered Kubernetes and are using static -Pods to run a Pod on every node, you should probably be using a -{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} -instead. +複数ノードからなるKubernetesクラスターを実行していて、Podをすべてのノード上で実行するためにstatic Podを使用している場合、おそらくstatic Podの代わりに{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}を使用するべきでしょう。 {{< /note >}} - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods, -and that your nodes are running the Fedora operating system. -Instructions for other distributions or Kubernetes installations may vary. - - - - +このページの説明では、Podを実行するために{{< glossary_tooltip term_id="docker" >}}を使用しており、ノード上のOSがFedoraであることを前提としています。他のディストリビューションやKubernetesのインストール方法によっては、操作が異なる場合があります。 -## Create a static pod {#static-pod-creation} +## static Podを作成する {#static-pod-creation} -You can configure a static Pod with either a [file system hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#configuration-files) or a [web hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http). +static Podは、[ファイルシステム上でホストされた設定ファイル](#configuration-files)または[ウェブ上でホストされた設定ファイル](/#pods-created-via-http)を使用して設定できます。 -### Filesystem-hosted static Pod manifest {#configuration-files} +### ファイルシステム上でホストされたstatic Podマニフェスト {#configuration-files} -Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: ` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there. -Note that the kubelet will ignore files starting with dots when scanning the specified directory. +マニフェストは、JSONまたはYAML形式の標準のPod定義で、特定のディレクトリに置きます。[kubeletの設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file)の中で、`staticPodPath: <ディレクトリの場所>`というフィールドを使用すると、kubeletがこのディレクトリを定期的にスキャンして、YAML/JSONファイルが作成/削除されるたびに、static Podの作成/削除が行われるようになります。指定したディレクトリをスキャンする際、kubeletはドットから始まる名前のファイルを無視することに注意してください。 -For example, this is how to start a simple web server as a static Pod: +例として、単純なウェブサーバーをstatic Podとして実行する方法を示します。 -1. Choose a node where you want to run the static Pod. In this example, it's `my-node1`. +1. static Podを実行したいノードを選択します。この例では、`my-node1`です。 ```shell ssh my-node1 ``` -2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`: +2. ディレクトリを選び(ここでは`/etc/kubelet.d`とします)、ここにウェブサーバーのPodの定義を置きます。たとえば、`/etc/kubelet.d/static-web.yaml`に置きます。 ```shell - # Run this command on the node where kubelet is running + # このコマンドは、kubeletが実行中のノード上で実行してください mkdir /etc/kubelet.d/ cat </etc/kubelet.d/static-web.yaml apiVersion: v1 @@ -87,31 +64,28 @@ For example, this is how to start a simple web server as a static Pod: EOF ``` -3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line: +3. ノード上のkubeletがこのディレクトリを使用するようにするために、`--pod-manifest-path=/etc/kubelet.d/`引数を付けてkubeletを実行するように設定します。Fedoraの場合、次の行が含まれるように`/etc/kubernetes/kubelet`を編集します。 ``` KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" ``` - or add the `staticPodPath: ` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file). -4. Restart the kubelet. On Fedora, you would run: + あるいは、[kubeletの設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file)に、`staticPodPath: <ディレクトリの場所>`フィールドを追加することでも設定できます。 + +4. kubeletを再起動します。Fedoraの場合、次のコマンドを実行します。 ```shell - # Run this command on the node where the kubelet is running + # このコマンドは、kubeletが実行中のノード上で実行してください systemctl restart kubelet ``` -### Web-hosted static pod manifest {#pods-created-via-http} +### ウェブ上でホストされたstatic Podマニフェスト {#pods-created-via-http} -Kubelet periodically downloads a file specified by `--manifest-url=` argument -and interprets it as a JSON/YAML file that contains Pod definitions. -Similar to how [filesystem-hosted manifests](#configuration-files) work, the kubelet -refetches the manifest on a schedule. If there are changes to the list of static -Pods, the kubelet applies them. +kubeletは、`--manifest-url=`引数で指定されたファイルを定期的にダウンロードし、Podの定義が含まれたJSON/YAMLファイルとして解釈します。kubeletは、[ファイルシステム上でホストされたマニフェスト](#configuration-files)での動作方法と同じように、定期的にマニフェストを再取得します。static Podのリスト中に変更が見つかると、kubeletがその変更を適用します。 -To use this approach: +このアプローチを採用する場合、次のように設定します。 -1. Create a YAML file and store it on a web server so that you can pass the URL of that file to the kubelet. +1. YAMLファイルを作成し、kubeletにファイルのURLを渡せるようにするために、ウェブサーバー上に保存する。 ```yaml apiVersion: v1 @@ -130,39 +104,38 @@ To use this approach: protocol: TCP ``` -2. Configure the kubelet on your selected node to use this web manifest by running it with `--manifest-url=`. On Fedora, edit `/etc/kubernetes/kubelet` to include this line: +2. 選択したノード上のkubeletを`--manifest-url=`を使用して実行することで、このウェブ上のマニフェストを使用するように設定する。Fedoraの場合、`/etc/kubernetes/kubelet`に次の行が含まれるように編集します。 ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<マニフェストのURL" ``` -3. Restart the kubelet. On Fedora, you would run: +3. kubeletを再起動する。Fedoraの場合、次のコマンドを実行します。 ```shell - # Run this command on the node where the kubelet is running + # このコマンドは、kubeletが実行中のノード上で実行してください systemctl restart kubelet ``` -## Observe static pod behavior {#behavior-of-static-pods} +## static Podの動作を観察する {#behavior-of-static-pods} -When the kubelet starts, it automatically starts all defined static Pods. As you have -defined a static Pod and restarted the kubelet, the new static Pod should -already be running. +kubeletが起動すると、定義されたすべてのstatic Podを起動します。ここまででstatic Podを設定してkubeletを再起動したため、すでに新しいstatic Podが実行中になっているはずです。 + +次のコマンドを(ノード上で)実行することで、(static Podを含む)実行中のコンテナを確認できます。 -You can view running containers (including static Pods) by running (on the node): ```shell -# Run this command on the node where the kubelet is running +# このコマンドは、kubeletが実行中のノード上で実行してください docker ps ``` -The output might be something like: +出力は次のようになります。 ``` CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` -You can see the mirror Pod on the API server: +APIサーバー上では、ミラーPodを確認できます。 ```shell kubectl get pods @@ -173,17 +146,13 @@ static-web-my-node1 1/1 Running 0 2m ``` {{< note >}} -Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See -[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/). +kubeletにAPIサーバー上のミラーPodを作成する権限があることを確認してください。もし権限がない場合、APIサーバーによって作成のリクエストが拒否されてしまいます。詳しくは、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)を参照してください。 {{< /note >}} -{{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are -propagated into the mirror Pod. You can use those labels as normal via -{{< glossary_tooltip term_id="selector" text="selectors" >}}, etc. +static Podに付けた{{< glossary_tooltip term_id="label" text="ラベル" >}}はミラーPodに伝搬します。ミラーPodに付けたラベルは、通常のPodと同じように{{< glossary_tooltip term_id="selector" text="セレクター" >}}などから利用できます。 -If you try to use `kubectl` to delete the mirror Pod from the API server, -the kubelet _doesn't_ remove the static Pod: +もし`kubectl`を使用してAPIサーバーからミラーPodを削除しようとしても、kubeletはstatic Podを削除*しません*。 ```shell kubectl delete pod static-web-my-node1 @@ -191,7 +160,9 @@ kubectl delete pod static-web-my-node1 ``` pod "static-web-my-node1" deleted ``` -You can see that the Pod is still running: + +Podはまだ実行中であることがわかります。 + ```shell kubectl get pods ``` @@ -200,14 +171,11 @@ NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s ``` -Back on your node where the kubelet is running, you can try to stop the Docker -container manually. -You'll see that, after a time, the kubelet will notice and will restart the Pod -automatically: +kubeletが実行中のノードに戻り、Dockerコンテナを手動で停止してみることができます。しばらくすると、kubeletが変化に気づき、Podを自動的に再起動することがわかります。 ```shell -# Run these commands on the node where the kubelet is running -docker stop f6d05272b57e # replace with the ID of your container +# このコマンドは、kubeletが実行中のノード上で実行してください +docker stop f6d05272b57e # 実際のコンテナIDと置き換えてください sleep 20 docker ps ``` @@ -216,13 +184,13 @@ CONTAINER ID IMAGE COMMAND CREATED ... 5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... ``` -## Dynamic addition and removal of static pods +## static Podの動的な追加と削除 -The running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes Pods as files appear/disappear in this directory. +実行中のkubeletは設定ディレクトリ(この例では`/etc/kubelet.d`)の変更を定期的にスキャンし、このディレクトリ内にファイルが追加/削除されると、Podの追加/削除を行います。 ```shell # This assumes you are using filesystem-hosted static Pod configuration -# Run these commands on the node where the kubelet is running +# このコマンドは、kubeletが実行中のノード上で実行してください # mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 @@ -236,5 +204,3 @@ docker ps CONTAINER ID IMAGE COMMAND CREATED ... e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago ``` - - From 02723a22c452b99f74ec97785e55df9a17385d53 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Tue, 18 Aug 2020 14:30:01 +0900 Subject: [PATCH 09/11] Fix a typo Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/docker.md b/content/ja/docs/reference/glossary/docker.md index 3f839679d2..77f24ad6b8 100755 --- a/content/ja/docs/reference/glossary/docker.md +++ b/content/ja/docs/reference/glossary/docker.md @@ -14,4 +14,4 @@ Docker(正確にはDocker Engine)は、{{< glossary_tooltip text="コンテナ" -Dockerは、croupsやカーネル名前空間などのLinuxカーネルのリソースの隔離機能、OverlayFSなどの統合能力のあるファイルシステム、独立したコンテナを単一のLinuxインスタンス内で実行可能にするその他の機能などを利用して、マシンレベルでの仮想マシン(VM)の起動にかかるオーバーヘッドを回避します。 +Dockerは、cgroupsやカーネル名前空間などのLinuxカーネルのリソースの隔離機能、OverlayFSなどの統合能力のあるファイルシステム、独立したコンテナを単一のLinuxインスタンス内で実行可能にするその他の機能などを利用して、マシンレベルでの仮想マシン(VM)の起動にかかるオーバーヘッドを回避します。 From 1d8e787724da8d8bf5ba44291356ec60f7978613 Mon Sep 17 00:00:00 2001 From: cyberblack28 Date: Wed, 19 Aug 2020 00:51:57 +0900 Subject: [PATCH 10/11] Update content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 問題ないです。 Co-authored-by: nasa9084 --- .../windows/user-guide-windows-containers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 253f5a8874..f67c4fdcd3 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -111,7 +111,7 @@ spec: ログは可観測性の重要な要素です。これにより、ユーザーはワークロードの運用面に関する洞察を得ることができ、問題のトラブルシューティングの主要な要素になります。WindowsコンテナとWindowsコンテナ内のワークロードの動作はLinuxコンテナとは異なるため、ユーザーはログの収集に苦労し、運用の可視性が制限されていました。たとえば、Windowsワークロードは通常、ETW(Windowsのイベントトレース)にログを記録するか、アプリケーションイベントログにエントリをプッシュするように構成されます。Microsoftのオープンソースツールである[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)は、Windowsコンテナ内の構成されたログソースを監視するための推奨方法です。LogMonitorは、イベントログ、ETWプロバイダー、カスタムアプリケーションログのモニタリングをサポートしており、それらをSTDOUTにパイプして、`kubectl logs `で使用できます。 -LogMonitor GitHubページの指示に従って、バイナリと構成ファイルをすべてのコンテナにコピーして、LogMonitorがログをSTDOUTにプッシュするために必要なエントリポイントを追加します。 +LogMonitor GitHubページの指示に従って、バイナリと構成ファイルをすべてのコンテナにコピーして、LogMonitorがログをSTDOUTにプッシュするために必要なエントリーポイントを追加します。 ## 構成可能なコンテナのユーザー名の使用 @@ -241,4 +241,4 @@ spec: app: iis-2019 ``` -[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ \ No newline at end of file +[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ From 9d8efe0a959637a74d24d0918d72ce18a8c3a014 Mon Sep 17 00:00:00 2001 From: cyberblack28 Date: Wed, 19 Aug 2020 00:52:23 +0900 Subject: [PATCH 11/11] Update content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 問題ないです。 Co-authored-by: nasa9084 --- .../windows/user-guide-windows-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index f67c4fdcd3..e19c795d63 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -115,7 +115,7 @@ LogMonitor GitHubページの指示に従って、バイナリと構成ファイ ## 構成可能なコンテナのユーザー名の使用 -Kubernetes v1.16以降、Windowsコンテナは、イメージのデフォルトとは異なるユーザー名でエントリポイントとプロセスを実行するように構成できます。これが達成される方法は、Linuxコンテナで行われる方法とは少し異なります。詳しくは[こちら](/docs/tasks/configure-pod-container/configure-runasusername/). +Kubernetes v1.16以降、Windowsコンテナは、イメージのデフォルトとは異なるユーザー名でエントリーポイントとプロセスを実行するように構成できます。これが達成される方法は、Linuxコンテナで行われる方法とは少し異なります。詳しくは[こちら](/docs/tasks/configure-pod-container/configure-runasusername/). ## Group Managed Service AccountsによるワークロードIDの管理