From 54436fa64774eea7c1a0e2f81acca3e9d4d6a68f Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 7 Aug 2020 07:42:00 +0900 Subject: [PATCH 001/303] Copy concepts/services-networking/network-policies.md from en/ directory. --- .../services-networking/network-policies.md | 225 ++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 content/ja/docs/concepts/services-networking/network-policies.md diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md new file mode 100644 index 0000000000..a35eca252f --- /dev/null +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -0,0 +1,225 @@ +--- +reviewers: +- thockin +- caseydavenport +- danwinship +title: Network Policies +content_type: concept +weight: 50 +--- + + +A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints. + +NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods. + + + + +## Prerequisites + +Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. + +## Isolated and Non-isolated Pods + +By default, pods are non-isolated; they accept traffic from any source. + +Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.) + +Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result. + +## The NetworkPolicy resource {#networkpolicy-resource} + +See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource. + +An example NetworkPolicy might look like this: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 +``` + +{{< note >}} +POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy. +{{< /note >}} + +__Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy +needs `apiVersion`, `kind`, and `metadata` fields. For general information +about working with config files, see +[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +and [Object Management](/docs/concepts/overview/working-with-objects/object-management). + +__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. + +__podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. + +__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. + +__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. + +__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. + +So, the example NetworkPolicy: + +1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated) +2. (Ingress rules) allows connections to all pods in the “default” namespace with the label “role=db” on TCP port 6379 from: + + * any pod in the "default" namespace with the label "role=frontend" + * any pod in a namespace with the label "project=myproject" + * IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24) +3. (Egress rules) allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978 + +See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. + +## Behavior of `to` and `from` selectors + +There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section: + +__podSelector__: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations. + +__namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations. + +__namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + podSelector: + matchLabels: + role: client + ... +``` + +contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + - podSelector: + matchLabels: + role: client + ... +``` + +contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. + +When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy. + +__ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. + +Cluster ingress and egress mechanisms often require rewriting the source or destination IP +of packets. In cases where this happens, it is not defined whether this happens before or +after NetworkPolicy processing, and the behavior may be different for different +combinations of network plugin, cloud provider, `Service` implementation, etc. + +In the case of ingress, this means that in some cases you may be able to filter incoming +packets based on the actual original source IP, while in other cases, the "source IP" that +the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc. + +For egress, this means that connections from pods to `Service` IPs that get rewritten to +cluster-external IPs may or may not be subject to `ipBlock`-based policies. + +## Default policies + +By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior +in that namespace. + +### Default deny all ingress traffic + +You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. + +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} + +This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior. + +### Default allow all ingress traffic + +If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace. + +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} + +### Default deny all egress traffic + +You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. + +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} + +This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not +change the default ingress isolation behavior. + +### Default allow all egress traffic + +If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace. + +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} + +### Default deny all ingress and all egress traffic + +You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. + +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} + +This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic. + +## SCTP support + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`. +When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. + +{{< note >}} +You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. +{{< /note >}} + + + + +## {{% heading "whatsnext" %}} + + +- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) + walkthrough for further examples. +- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. + + From 5cc86c82f8244e9e067e4a1732a1c4c9a2e3a772 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 7 Aug 2020 09:25:48 +0900 Subject: [PATCH 002/303] Add example resources. --- .../networking/network-policy-allow-all-egress.yaml | 11 +++++++++++ .../networking/network-policy-allow-all-ingress.yaml | 11 +++++++++++ .../networking/network-policy-default-deny-all.yaml | 10 ++++++++++ .../network-policy-default-deny-egress.yaml | 9 +++++++++ .../network-policy-default-deny-ingress.yaml | 9 +++++++++ 5 files changed, 50 insertions(+) create mode 100644 content/ja/examples/service/networking/network-policy-allow-all-egress.yaml create mode 100644 content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml create mode 100644 content/ja/examples/service/networking/network-policy-default-deny-all.yaml create mode 100644 content/ja/examples/service/networking/network-policy-default-deny-egress.yaml create mode 100644 content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml diff --git a/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml b/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/ja/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/ja/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/ja/examples/service/networking/network-policy-default-deny-all.yaml b/content/ja/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/ja/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml b/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/ja/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/ja/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress From 0cc2b2a1df48b3344bd739def7a238d071a46720 Mon Sep 17 00:00:00 2001 From: nishipy Date: Fri, 14 Aug 2020 21:11:06 +0900 Subject: [PATCH 003/303] Translate concepts/cluster-administration/cloud-providers/ into Japanese --- .../cluster-administration/cloud-providers.md | 327 ++++++++++++++++++ 1 file changed, 327 insertions(+) create mode 100644 content/ja/docs/concepts/cluster-administration/cloud-providers.md diff --git a/content/ja/docs/concepts/cluster-administration/cloud-providers.md b/content/ja/docs/concepts/cluster-administration/cloud-providers.md new file mode 100644 index 0000000000..91881a178a --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/cloud-providers.md @@ -0,0 +1,327 @@ +--- +title: クラウドプロバイダー +content_type: concept +weight: 30 +--- + + +このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。 + + +### kubeadm +[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。 +kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。 +例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。 + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" +--- +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +kubernetesVersion: v1.13.0 +apiServer: + extraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" + extraVolumes: + - name: cloud + hostPath: "/etc/kubernetes/cloud.conf" + mountPath: "/etc/kubernetes/cloud.conf" +controllerManager: + extraArgs: + cloud-provider: "openstack" + cloud-config: "/etc/kubernetes/cloud.conf" + extraVolumes: + - name: cloud + hostPath: "/etc/kubernetes/cloud.conf" + mountPath: "/etc/kubernetes/cloud.conf" +``` + +インツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。 +プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。 + +すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。 + +## AWS +ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。 + +この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。 + +### ノード名 + +AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。 + +### ロードバランサー +以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example + namespace: kube-system + labels: + run: example + annotations: + service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value + service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http +spec: + type: LoadBalancer + ports: + - port: 443 + targetPort: 5556 + protocol: TCP + selector: + app: example +``` +AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。 + +* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。 +* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。 +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。 +* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。 +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。 +* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。 +* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。 +* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。 + +AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。 + +## Azure + +この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。 + +### ノード名 + +Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。 + +## CloudStack + +この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。 + +### ノード名 + +CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 + +## GCE + +この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。 + +### ノード名 + +GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。 + +## HUAWEI CLOUD + +この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。 + +### ノード名 + +HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。 +ノードでkubeletを開始するときは、必ず`--hostname-override=`を指定してください。 + +## OpenStack +ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。 + +この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。 + +### ノード名 + +OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 +kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。 + +### サービス + +KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。 + +| サービス名 | APIバージョン | 必須か | +|--------------------------|----------------|----------| +| Block Storage (Cinder) | V1†, V2, V3 | No | +| Compute (Nova) | V2 | No | +| Identity (Keystone) | V2‡, V3 | Yes | +| Load Balancing (Neutron) | V1§, V2 | No | +| Load Balancing (Octavia) | V2 | No | + +† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。 + +‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。 + +§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。 + +サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。 +プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。 +特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。 + +### cloud.conf +Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。 +これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。 +ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。 + +#### 典型的な設定 +以下の設定例は、最も頻繁に設定が必要な値に関するものです。 +プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。 + +```yaml +[Global] +username=user +password=pass +auth-url=https:///identity/v3 +tenant-id=c869168a828847f39f7f06edd7305637 +domain-id=2a73b8f597c04551a0fdc8e95544be8a + +[LoadBalancer] +subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a +``` + +##### グローバル +これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。 + +* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。 +* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。 +* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。 +* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。 +* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。 +* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。 +* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。 +* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。 +* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。 +* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。 + + +テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。 + +##### ロードバランサー +これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。 + +* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。 +* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。 +* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。 +* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。 +* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。 +* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。 +* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。 +* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 +* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 +* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。 +* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。 +* `node-security-group`(任意): 管理するセキュリティーグループのIDです。 + +##### ブロックストレージ +これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。 + +* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。 +* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。 +* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。 +* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。 + +エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。 + +パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。 + +```yaml +[BlockStorage] +bs-version=v2 +``` + +##### メタデータ +これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。 + +* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。 + * `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。 + * `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。 + * `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。 + + コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。 + +##### ルート +これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。 + + +* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。 + +## OVirt + +### ノード名 + +OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名は、VMのFQDN(`...`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。 + +## Photon + +### ノード名 + +Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。 + +## vSphere + +{{< tabs name="vSphere cloud provider" >}} +{{% tab name="vSphere 6.7U3以上" %}} +vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。 +{{% /tab %}} +{{% tab name="vSphere 6.7U3未満" %}} +vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。 +{{% /tab %}} +{{< /tabs >}} + +vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。 + +## IBM Cloud Kubernetes Service + +### コンピュートノード +IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。 + +Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。 + +### ネットワーク +IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。 + +アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。 + +### ストレージ +IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。 + +## Baidu Cloud Container Engine + +### ノード名 + +Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。 + +## Tencent Kubernetes Engine + +この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。 + +### ノード名 + +Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 +Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。 + +## Alibaba Cloud Kubernetes + +この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。 + +### ノード名 + +Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。 + +### ロードバランサー + +[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。 From e5cee09476bdf1cf43b2cdd34caee6a9a8792a4e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 15 Aug 2020 02:45:01 +0900 Subject: [PATCH 004/303] Copy concepts/services-networking/endpoint-slices.md from en/ directory. --- .../services-networking/endpoint-slices.md | 186 ++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 content/ja/docs/concepts/services-networking/endpoint-slices.md diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md new file mode 100644 index 0000000000..7c66ce0072 --- /dev/null +++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md @@ -0,0 +1,186 @@ +--- +reviewers: +- freehan +title: EndpointSlices +content_type: concept +weight: 15 +--- + + + + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +_EndpointSlices_ provide a simple way to track network endpoints within a +Kubernetes cluster. They offer a more scalable and extensible alternative to +Endpoints. + + + + + +## Motivation + +The Endpoints API has provided a simple and straightforward way of +tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters +and Services have gotten larger, limitations of that API became more visible. +Most notably, those included challenges with scaling to larger numbers of +network endpoints. + +Since all network endpoints for a Service were stored in a single Endpoints +resource, those resources could get quite large. That affected the performance +of Kubernetes components (notably the master control plane) and resulted in +significant amounts of network traffic and processing when Endpoints changed. +EndpointSlices help you mitigate those issues as well as provide an extensible +platform for additional features such as topological routing. + +## EndpointSlice resources {#endpointslice-resource} + +In Kubernetes, an EndpointSlice contains references to a set of network +endpoints. The EndpointSlice controller automatically creates EndpointSlices +for a Kubernetes Service when a {{< glossary_tooltip text="selector" +term_id="selector" >}} is specified. These EndpointSlices will include +references to any Pods that match the Service selector. EndpointSlices group +network endpoints together by unique Service and Port combinations. +The name of a EndpointSlice object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +As an example, here's a sample EndpointSlice resource for the `example` +Kubernetes Service. + +```yaml +apiVersion: discovery.k8s.io/v1beta1 +kind: EndpointSlice +metadata: + name: example-abc + labels: + kubernetes.io/service-name: example +addressType: IPv4 +ports: + - name: http + protocol: TCP + port: 80 +endpoints: + - addresses: + - "10.1.2.3" + conditions: + ready: true + hostname: pod-1 + topology: + kubernetes.io/hostname: node-1 + topology.kubernetes.io/zone: us-west2-a +``` + +By default, EndpointSlices managed by the EndpointSlice controller will have no +more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 +with Endpoints and Services and have similar performance. + +EndpointSlices can act as the source of truth for kube-proxy when it comes to +how to route internal traffic. When enabled, they should provide a performance +improvement for services with large numbers of endpoints. + +### Address Types + +EndpointSlices support three address types: + +* IPv4 +* IPv6 +* FQDN (Fully Qualified Domain Name) + +### Topology + +Each endpoint within an EndpointSlice can contain relevant topology information. +This is used to indicate where an endpoint is, containing information about the +corresponding Node, zone, and region. When the values are available, the +following Topology labels will be set by the EndpointSlice controller: + +* `kubernetes.io/hostname` - The name of the Node this endpoint is on. +* `topology.kubernetes.io/zone` - The zone this endpoint is in. +* `topology.kubernetes.io/region` - The region this endpoint is in. + +The values of these labels are derived from resources associated with each +endpoint in a slice. The hostname label represents the value of the NodeName +field on the corresponding Pod. The zone and region labels represent the value +of the labels with the same names on the corresponding Node. + +### Management + +By default, EndpointSlices are created and managed by the EndpointSlice +controller. There are a variety of other use cases for EndpointSlices, such as +service mesh implementations, that could result in other entities or controllers +managing additional sets of EndpointSlices. To ensure that multiple entities can +manage EndpointSlices without interfering with each other, a +`endpointslice.kubernetes.io/managed-by` label is used to indicate the entity +managing an EndpointSlice. The EndpointSlice controller sets +`endpointslice-controller.k8s.io` as the value for this label on all +EndpointSlices it manages. Other entities managing EndpointSlices should also +set a unique value for this label. + +### Ownership + +In most use cases, EndpointSlices will be owned by the Service that it tracks +endpoints for. This is indicated by an owner reference on each EndpointSlice as +well as a `kubernetes.io/service-name` label that enables simple lookups of all +EndpointSlices belonging to a Service. + +## EndpointSlice Controller + +The EndpointSlice controller watches Services and Pods to ensure corresponding +EndpointSlices are up to date. The controller will manage EndpointSlices for +every Service with a selector specified. These will represent the IPs of Pods +matching the Service selector. + +### Size of EndpointSlices + +By default, EndpointSlices are limited to a size of 100 endpoints each. You can +configure this with the `--max-endpoints-per-slice` {{< glossary_tooltip +text="kube-controller-manager" term_id="kube-controller-manager" >}} flag up to +a maximum of 1000. + +### Distribution of EndpointSlices + +Each EndpointSlice has a set of ports that applies to all endpoints within the +resource. When named ports are used for a Service, Pods may end up with +different target port numbers for the same named port, requiring different +EndpointSlices. This is similar to the logic behind how subsets are grouped +with Endpoints. + +The controller tries to fill EndpointSlices as full as possible, but does not +actively rebalance them. The logic of the controller is fairly straightforward: + +1. Iterate through existing EndpointSlices, remove endpoints that are no longer + desired and update matching endpoints that have changed. +2. Iterate through EndpointSlices that have been modified in the first step and + fill them up with any new endpoints needed. +3. If there's still new endpoints left to add, try to fit them into a previously + unchanged slice and/or create new ones. + +Importantly, the third step prioritizes limiting EndpointSlice updates over a +perfectly full distribution of EndpointSlices. As an example, if there are 10 +new endpoints to add and 2 EndpointSlices with room for 5 more endpoints each, +this approach will create a new EndpointSlice instead of filling up the 2 +existing EndpointSlices. In other words, a single EndpointSlice creation is +preferrable to multiple EndpointSlice updates. + +With kube-proxy running on each Node and watching EndpointSlices, every change +to an EndpointSlice becomes relatively expensive since it will be transmitted to +every Node in the cluster. This approach is intended to limit the number of +changes that need to be sent to every Node, even if it may result with multiple +EndpointSlices that are not full. + +In practice, this less than ideal distribution should be rare. Most changes +processed by the EndpointSlice controller will be small enough to fit in an +existing EndpointSlice, and if not, a new EndpointSlice is likely going to be +necessary soon anyway. Rolling updates of Deployments also provide a natural +repacking of EndpointSlices with all pods and their corresponding endpoints +getting replaced. + + + +## {{% heading "whatsnext" %}} + + +* [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices) +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) + + From 18a599be6c687c8c0dd2e37b06e58fda56c336b6 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 7 Aug 2020 07:42:20 +0900 Subject: [PATCH 005/303] Translate concepts/services-networking/network-policies into Japanese. --- .../services-networking/network-policies.md | 145 ++++++++---------- 1 file changed, 60 insertions(+), 85 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index a35eca252f..9dc3031abb 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -1,38 +1,33 @@ --- -reviewers: -- thockin -- caseydavenport -- danwinship -title: Network Policies +title: ネットワークポリシー content_type: concept weight: 50 --- -A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints. - -NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods. +ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。 +NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。 -## Prerequisites +## 前提条件 -Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. +ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。 -## Isolated and Non-isolated Pods +## 分離されたPodと分離されていないPod -By default, pods are non-isolated; they accept traffic from any source. +デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。 -Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.) +Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。 -Network policies do not conflict; they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result. +ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。 -## The NetworkPolicy resource {#networkpolicy-resource} +## NetworkPolicyリソース {#networkpolicy-resource} -See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource. +リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。 -An example NetworkPolicy might look like this: +以下は、NetworkPolicyの一例です。 ```yaml apiVersion: networking.k8s.io/v1 @@ -72,46 +67,42 @@ spec: ``` {{< note >}} -POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy. +選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。 {{< /note >}} -__Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy -needs `apiVersion`, `kind`, and `metadata` fields. For general information -about working with config files, see -[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), -and [Object Management](/docs/concepts/overview/working-with-objects/object-management). +__必須フィールド__: 他のKubernetesの設定と同様に、NetworkPolicyにも`apiVersion`、`kind`、`metadata`フィールドが必須です。設定ファイルの扱い方に関する一般的な情報については、[ConfigMapを使用してコンテナを構成する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)と[オブジェクト管理](/ja/docs/concepts/overview/working-with-objects/object-management)を参照してください。 -__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. +__spec__: NetworkPolicyの[spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。 -__podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace. +__podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。 -__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. +__policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に +`Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。 -__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. +__ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。 -__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. +__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。 -So, the example NetworkPolicy: +したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。 -1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated) -2. (Ingress rules) allows connections to all pods in the “default” namespace with the label “role=db” on TCP port 6379 from: +1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(すでに分離されていなければ) +2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する + * "default"名前空間内のラベル"role=frontend"が付いたすべてのPod + * ラベル"project=myproject"が付いた名前空間内のすべてのPod + * 172.17.0.0–172.17.0.255および172.17.2.0–172.17.255.255(言い換えれば、172.17.1.0/24の範囲を除く172.17.0.0/16)の範囲内のすべてのIPアドレス +3. (Egressルール) "role=db"というラベルが付いた"default"名前空間内のすべてのPodからの、TCPの5978番ポート上でのCIDR 10.0.0.0/24への接続を許可する - * any pod in the "default" namespace with the label "role=frontend" - * any pod in a namespace with the label "project=myproject" - * IP addresses in the ranges 172.17.0.0–172.17.0.255 and 172.17.2.0–172.17.255.255 (ie, all of 172.17.0.0/16 except 172.17.1.0/24) -3. (Egress rules) allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978 +追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。 -See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. +## `to`と`from`のセレクターの振る舞い -## Behavior of `to` and `from` selectors +`ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。 -There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section: +__podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。 -__podSelector__: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations. +__namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。 -__namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations. - -__namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that specifies both `namespaceSelector` and `podSelector` selects particular Pods within particular namespaces. Be careful to use correct YAML syntax; this policy: +__namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。 ```yaml ... @@ -126,7 +117,7 @@ __namespaceSelector__ *and* __podSelector__: A single `to`/`from` entry that spe ... ``` -contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy: +このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の追加Podからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。 ```yaml ... @@ -141,85 +132,69 @@ contains a single `from` element allowing connections from Pods with the label ` ... ``` -contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. +このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。 -When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy. +正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。 -__ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. +__ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。 -Cluster ingress and egress mechanisms often require rewriting the source or destination IP -of packets. In cases where this happens, it is not defined whether this happens before or -after NetworkPolicy processing, and the behavior may be different for different -combinations of network plugin, cloud provider, `Service` implementation, etc. +クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。 -In the case of ingress, this means that in some cases you may be able to filter incoming -packets based on the actual original source IP, while in other cases, the "source IP" that -the NetworkPolicy acts on may be the IP of a `LoadBalancer` or of the Pod's node, etc. +内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。 -For egress, this means that connections from pods to `Service` IPs that get rewritten to -cluster-external IPs may or may not be subject to `ipBlock`-based policies. +外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。 -## Default policies +## デフォルトのポリシー -By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. The following examples let you change the default behavior -in that namespace. +デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。 -### Default deny all ingress traffic +### デフォルトですべての内向きのトラフィックを拒否する -You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. +すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior. +このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。 -### Default allow all ingress traffic +### デフォルトで内向きのすべてのトラフィックを許可する -If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace. +(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} -### Default deny all egress traffic +### デフォルトで外向きのすべてのトラフィックを拒否する -You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods. +すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} -This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not -change the default ingress isolation behavior. +このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。 -### Default allow all egress traffic +### デフォルトで外向きのすべてのトラフィックを許可する -If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace. +(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} -### Default deny all ingress and all egress traffic +### デフォルトで内向きと外向きのすべてのトラフィックを拒否する -You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace. +名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} -This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic. +このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。 -## SCTP support +## SCTPのサポート {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`. -When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. +この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。 {{< note >}} -You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. +SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。 {{< /note >}} - - - ## {{% heading "whatsnext" %}} - -- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) - walkthrough for further examples. -- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. - - +- [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。 +- NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。 From 7f9bc793c06d170fd041038e2845689b6b5464c9 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 19 Aug 2020 22:36:53 +0900 Subject: [PATCH 006/303] Improve the translation of a phrase --- .../ja/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index 9dc3031abb..c065f78e66 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -85,7 +85,7 @@ __egress__: 各NetworkPolicyには、許可する`egress`ルールのリスト したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。 -1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(すでに分離されていなければ) +1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(まだ分離されていない場合) 2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する * "default"名前空間内のラベル"role=frontend"が付いたすべてのPod * ラベル"project=myproject"が付いた名前空間内のすべてのPod From 41f9de3fe289c8d167c9707e5e23931d17443e95 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 23:05:31 +0900 Subject: [PATCH 007/303] Translate missing sentences. --- .../ja/docs/concepts/services-networking/network-policies.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index c065f78e66..b053171043 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -19,9 +19,9 @@ NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="la デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。 -Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。 +Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(名前空間内でもどのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。) -ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。 +ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。 ## NetworkPolicyリソース {#networkpolicy-resource} From 942102719246c826233c1eeb626e16941f6c32fa Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 23:07:58 +0900 Subject: [PATCH 008/303] Fix two typos Co-authored-by: Naoki Oketani --- .../ja/docs/concepts/services-networking/network-policies.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index b053171043..68317ab1ca 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -81,7 +81,7 @@ __policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、` __ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。 -__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。 +__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。 したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。 @@ -117,7 +117,7 @@ __namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エ ... ``` -このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の追加Podからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。 +このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。 ```yaml ... From 3cd16e676af8fd2e2cb3e47f0f48f5d5e7987f43 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 15 Aug 2020 02:45:40 +0900 Subject: [PATCH 009/303] Translate concepts/services-networking/endpoint-slices into Japanese. --- .../services-networking/endpoint-slices.md | 153 +++++------------- 1 file changed, 38 insertions(+), 115 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md index 7c66ce0072..8d4e124855 100644 --- a/content/ja/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md @@ -1,52 +1,28 @@ --- -reviewers: -- freehan -title: EndpointSlices +title: EndpointSlice content_type: concept weight: 15 --- - {{< feature-state for_k8s_version="v1.17" state="beta" >}} -_EndpointSlices_ provide a simple way to track network endpoints within a -Kubernetes cluster. They offer a more scalable and extensible alternative to -Endpoints. - - +*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能なEndpointの代わりとなるものです。 -## Motivation +## 動機 -The Endpoints API has provided a simple and straightforward way of -tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters -and Services have gotten larger, limitations of that API became more visible. -Most notably, those included challenges with scaling to larger numbers of -network endpoints. +Endpoints APIは、Kubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。 -Since all network endpoints for a Service were stored in a single Endpoints -resource, those resources could get quite large. That affected the performance -of Kubernetes components (notably the master control plane) and resulted in -significant amounts of network traffic and processing when Endpoints changed. -EndpointSlices help you mitigate those issues as well as provide an extensible -platform for additional features such as topological routing. +Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。 -## EndpointSlice resources {#endpointslice-resource} +## EndpointSliceリソース {#endpointslice-resource} -In Kubernetes, an EndpointSlice contains references to a set of network -endpoints. The EndpointSlice controller automatically creates EndpointSlices -for a Kubernetes Service when a {{< glossary_tooltip text="selector" -term_id="selector" >}} is specified. These EndpointSlices will include -references to any Pods that match the Service selector. EndpointSlices group -network endpoints together by unique Service and Port combinations. -The name of a EndpointSlice object must be a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Kubernetes内では、EndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceには、Serviceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceは、ネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 -As an example, here's a sample EndpointSlice resource for the `example` -Kubernetes Service. +一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。 ```yaml apiVersion: discovery.k8s.io/v1beta1 @@ -71,116 +47,63 @@ endpoints: topology.kubernetes.io/zone: us-west2-a ``` -By default, EndpointSlices managed by the EndpointSlice controller will have no -more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 -with Endpoints and Services and have similar performance. +デフォルトでは、EndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceは、EndpointとServiceが1対1対応になり、性能は変わらないはずです。 -EndpointSlices can act as the source of truth for kube-proxy when it comes to -how to route internal traffic. When enabled, they should provide a performance -improvement for services with large numbers of endpoints. +EndpointSliceは、内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。 -### Address Types +### アドレスの種類 -EndpointSlices support three address types: +EndpointSliceは、次の3種類のアドレスをサポートします。 * IPv4 * IPv6 -* FQDN (Fully Qualified Domain Name) +* FQDN (Fully Qualified Domain Name、完全修飾ドメイン名) -### Topology +### トポロジー -Each endpoint within an EndpointSlice can contain relevant topology information. -This is used to indicate where an endpoint is, containing information about the -corresponding Node, zone, and region. When the values are available, the -following Topology labels will be set by the EndpointSlice controller: +EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合には、EndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。 -* `kubernetes.io/hostname` - The name of the Node this endpoint is on. -* `topology.kubernetes.io/zone` - The zone this endpoint is in. -* `topology.kubernetes.io/region` - The region this endpoint is in. +* `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。 +* `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。 +* `topology.kubernetes.io/region` - このエンドポイントが存在するリージョン。 -The values of these labels are derived from resources associated with each -endpoint in a slice. The hostname label represents the value of the NodeName -field on the corresponding Pod. The zone and region labels represent the value -of the labels with the same names on the corresponding Node. +これらのラベルの値は、スライス内の各エンドポイントと関連するリソースから継承したものです。hostnameラベルは、対応するPod上のNodeNameフィールドの値を表します。zoneとregionラベルは、対応するNode上の同じ名前のラベルの値を表します。 -### Management +### 管理 -By default, EndpointSlices are created and managed by the EndpointSlice -controller. There are a variety of other use cases for EndpointSlices, such as -service mesh implementations, that could result in other entities or controllers -managing additional sets of EndpointSlices. To ensure that multiple entities can -manage EndpointSlices without interfering with each other, a -`endpointslice.kubernetes.io/managed-by` label is used to indicate the entity -managing an EndpointSlice. The EndpointSlice controller sets -`endpointslice-controller.k8s.io` as the value for this label on all -EndpointSlices it manages. Other entities managing EndpointSlices should also -set a unique value for this label. +EndpointSliceは、デフォルトではEndpointSliceコントローラによって作成・管理されます。EndpointSliceには、他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 -### Ownership +### 所有権 -In most use cases, EndpointSlices will be owned by the Service that it tracks -endpoints for. This is indicated by an owner reference on each EndpointSlice as -well as a `kubernetes.io/service-name` label that enables simple lookups of all -EndpointSlices belonging to a Service. +ほとんどのユースケースでは、EndpointSliceは、対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと、`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。 -## EndpointSlice Controller +## EndpointSliceコントローラー -The EndpointSlice controller watches Services and Pods to ensure corresponding -EndpointSlices are up to date. The controller will manage EndpointSlices for -every Service with a selector specified. These will represent the IPs of Pods -matching the Service selector. +EndpointSliceコントローラーは、対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーは、セレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceは、Serviceセレクターに一致するPodのIPを表します。 -### Size of EndpointSlices +### EndpointSliceのサイズ -By default, EndpointSlices are limited to a size of 100 endpoints each. You can -configure this with the `--max-endpoints-per-slice` {{< glossary_tooltip -text="kube-controller-manager" term_id="kube-controller-manager" >}} flag up to -a maximum of 1000. +デフォルトでは、それぞれのEndpointSliceのサイズの上限は、100のEndpointsまでに制限されています。この制限は、{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。 -### Distribution of EndpointSlices +### EndpointSliceの分散 -Each EndpointSlice has a set of ports that applies to all endpoints within the -resource. When named ports are used for a Service, Pods may end up with -different target port numbers for the same named port, requiring different -EndpointSlices. This is similar to the logic behind how subsets are grouped -with Endpoints. +それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これは、サービスの部分集合がEndpointsにグループ化される場合と同様です。 -The controller tries to fill EndpointSlices as full as possible, but does not -actively rebalance them. The logic of the controller is fairly straightforward: +コントローラーは、EndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。 -1. Iterate through existing EndpointSlices, remove endpoints that are no longer - desired and update matching endpoints that have changed. -2. Iterate through EndpointSlices that have been modified in the first step and - fill them up with any new endpoints needed. -3. If there's still new endpoints left to add, try to fit them into a previously - unchanged slice and/or create new ones. - -Importantly, the third step prioritizes limiting EndpointSlice updates over a -perfectly full distribution of EndpointSlices. As an example, if there are 10 -new endpoints to add and 2 EndpointSlices with room for 5 more endpoints each, -this approach will create a new EndpointSlice instead of filling up the 2 -existing EndpointSlices. In other words, a single EndpointSlice creation is -preferrable to multiple EndpointSlice updates. +1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。 +2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。 +3. まだ追加するべき新しいエンドポイントが残っていた場合、これまで変更されなかったスライスに追加を試み、その後、新しいスライスを作成する。 -With kube-proxy running on each Node and watching EndpointSlices, every change -to an EndpointSlice becomes relatively expensive since it will be transmitted to -every Node in the cluster. This approach is intended to limit the number of -changes that need to be sent to every Node, even if it may result with multiple -EndpointSlices that are not full. - -In practice, this less than ideal distribution should be rare. Most changes -processed by the EndpointSlice controller will be small enough to fit in an -existing EndpointSlice, and if not, a new EndpointSlice is likely going to be -necessary soon anyway. Rolling updates of Deployments also provide a natural -repacking of EndpointSlices with all pods and their corresponding endpoints -getting replaced. +ここで重要なのは、3番目のステップでEndpointSliceを完全に分散させることよりも、EndpointSliceの更新を制限することを優先していることです。たとえば、もし新しい追加するべきエンドポイントが10個あり、2つのEndpointSliceにそれぞれ5個の空きがあった場合、このアプローチでは、2つの既存のEndpointSliceを充填する代わりに、新しいEndpointSliceが作られます。言い換えれば、1つのEndpointSliceを作成する方が、複数のEndpointSliceを更新するよりも好ましいということです。 +各Node上で実行されているkube-proxyはEndpointSliceを監視しており、EndpointSliceに加えられた変更はクラスター内のすべてのNodeに送信されるため、比較的コストの高い処理になります。先ほどのアプローチは、たとえ複数のEndpointSliceが充填されない結果となるとしても、すべてのNodeへ送信しなければならない変更の数を抑制することを目的としています。 +現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントが、すべて置換されるためです。 ## {{% heading "whatsnext" %}} - -* [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices) -* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) +* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices) +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む From 0008b72fbd22a9a8d79d05b337bc905d9922564f Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 18 Sep 2020 07:26:45 +0900 Subject: [PATCH 010/303] Improve a bad translation. --- .../ja/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index 68317ab1ca..61a798b947 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -19,7 +19,7 @@ NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="la デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。 -Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(名前空間内でもどのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。) +Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。) ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。 From c6e165f5af4c52c65055a9f751bf06c03b7e0c01 Mon Sep 17 00:00:00 2001 From: Saintmalik Date: Wed, 14 Oct 2020 11:52:03 +0000 Subject: [PATCH 011/303] Fix broken url in docs --- content/en/docs/setup/release/notes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md index a167556594..45791de15b 100644 --- a/content/en/docs/setup/release/notes.md +++ b/content/en/docs/setup/release/notes.md @@ -2441,7 +2441,7 @@ filename | sha512 hash - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] - BlockVolume and CSIBlockVolume features are now GA. ([#88673](https://github.com/kubernetes/kubernetes/pull/88673), [@jsafrane](https://github.com/jsafrane)) [SIG Apps, Node and Storage] - Consumers of the 'certificatesigningrequests/approval' API must now grant permission to 'approve' CSRs for the 'signerName' specified on the CSR. More information on the new signerName field can be found at https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190607-certificates-api.md#signers ([#88246](https://github.com/kubernetes/kubernetes/pull/88246), [@munnerz](https://github.com/munnerz)) [SIG API Machinery, Apps, Auth, CLI, Node and Testing] -- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] +- CustomResourceDefinition schemas that use `x-kubernetes-list-map-keys` to specify properties that uniquely identify list items must make those properties required or have a default value, to ensure those properties are present for all list items. See https://kubernetes.io/docs/reference/using-api/api-concepts/#merge-strategy for details. ([#88076](https://github.com/kubernetes/kubernetes/pull/88076), [@eloyekunle](https://github.com/eloyekunle)) [SIG API Machinery and Testing] - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] - Fixes a regression with clients prior to 1.15 not being able to update podIP in pod status, or podCIDR in node spec, against >= 1.16 API servers ([#88505](https://github.com/kubernetes/kubernetes/pull/88505), [@liggitt](https://github.com/liggitt)) [SIG Apps and Network] - Ingress: Add Exact and Prefix maching to Ingress PathTypes ([#88587](https://github.com/kubernetes/kubernetes/pull/88587), [@cmluciano](https://github.com/cmluciano)) [SIG Apps, Cluster Lifecycle and Network] From 2ff3d1f7d30028c466660a9b267439d532fcbcb8 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 13 Sep 2020 11:25:40 +0800 Subject: [PATCH 012/303] Improve ServiceAccount administration doc This PR fixes some nits in the doc and slightly revised the content to conform to content guidelines. --- .../service-accounts-admin.md | 126 ++++++++++-------- 1 file changed, 69 insertions(+), 57 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index df653a206f..8f094309e1 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -23,96 +23,108 @@ incomplete features are referred to in order to better describe service accounts Kubernetes distinguishes between the concept of a user account and a service account for a number of reasons: - - User accounts are for humans. Service accounts are for processes, which - run in pods. - - User accounts are intended to be global. Names must be unique across all - namespaces of a cluster, future user resource will not be namespaced. - Service accounts are namespaced. - - Typically, a cluster's User accounts might be synced from a corporate - database, where new user account creation requires special privileges and - is tied to complex business processes. Service account creation is intended - to be more lightweight, allowing cluster users to create service accounts for - specific tasks (i.e. principle of least privilege). - - Auditing considerations for humans and service accounts may differ. - - A config bundle for a complex system may include definition of various service - accounts for components of that system. Because service accounts can be created - ad-hoc and have namespaced names, such config is portable. +- User accounts are for humans. Service accounts are for processes, which run + in pods. +- User accounts are intended to be global. Names must be unique across all + namespaces of a cluster. Service accounts are namespaced. +- Typically, a cluster's user accounts might be synced from a corporate + database, where new user account creation requires special privileges and is + tied to complex business processes. Service account creation is intended to be + more lightweight, allowing cluster users to create service accounts for + specific tasks by following the principle of least privilege. +- Auditing considerations for humans and service accounts may differ. +- A config bundle for a complex system may include definition of various service + accounts for components of that system. Because service accounts can be created + without many constraints and have namespaced names, such config is portable. ## Service account automation Three separate components cooperate to implement the automation around service accounts: - - A Service account admission controller - - A Token controller - - A Service account controller +- A `ServiceAccount` admission controller +- A Token controller +- A `ServiceAccount` controller -### Service Account Admission Controller +### ServiceAccount Admission Controller The modification of pods is implemented via a plugin -called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). It is part of the apiserver. +called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). +It is part of the API server. It acts synchronously to modify pods as they are created or updated. When this plugin is active (and it is by default on most distributions), then it does the following when a pod is created or modified: - 1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`. - 1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it. - 1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod. - 1. It adds a `volume` to the pod which contains a token for API access. - 1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`. +1. If the pod does not have a `serviceAccountName` set, it sets the + `serviceAccountName` to `default`. +1. It ensures that the `serviceAccountName` referenced by the pod exists, and + otherwise rejects it. +1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` + of the ServiceAccount referenced by `serviceAccountName` are added to the pod. +1. It adds a `volume` to the pod which contains a token for API access + if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's + `automountServiceAccountToken` is set to `false`. +1. It adds a `volumeSource` to each container of the pod mounted at + `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has + created a volume for ServiceAccount token. -Starting from v1.13, you can migrate a service account volume to a projected volume when +You can migrate a service account volume to a projected volume when the `BoundServiceAccountTokenVolume` feature gate is enabled. -The service account token will expire after 1 hour or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). +The service account token will expire after 1 hour or the pod is deleted. See +more details about +[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). ### Token Controller -TokenController runs as part of controller-manager. It acts asynchronously. It: +TokenController runs as part of `kube-controller-manager`. It acts asynchronously. It: -- observes serviceAccount creation and creates a corresponding Secret to allow API access. -- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets. -- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed. -- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed. +- watches ServiceAccount creation and creates a corresponding + ServiceAccount token Secret to allow API access. +- watches ServiceAccount deletion and deletes all corresponding ServiceAccount + token Secrets. +- watches ServiceAccount token Secret addition, and ensures the referenced + ServiceAccount exists, and adds a token to the Secret if needed. +- watches Secret deletion and removes a reference from the corresponding + ServiceAccount if needed. -You must pass a service account private key file to the token controller in the controller-manager by using -the `--service-account-private-key-file` option. The private key will be used to sign generated service account tokens. -Similarly, you must pass the corresponding public key to the kube-apiserver using the `--service-account-key-file` -option. The public key will be used to verify the tokens during authentication. +You must pass a service account private key file to the token controller in +the `kube-controller-manager` using the `--service-account-private-key-file` +flag. The private key is used to sign generated service account tokens. +Similarly, you must pass the corresponding public key to the `kube-apiserver` +using the `--service-account-key-file` flag. The public key will be used to +verify the tokens during authentication. #### To create additional API tokens -A controller loop ensures a secret with an API token exists for each service -account. To create additional API tokens for a service account, create a secret -of type `ServiceAccountToken` with an annotation referencing the service -account, and the controller will update it with a generated token: +A controller loop ensures a Secret with an API token exists for each +ServiceAccount. To create additional API tokens for a ServiceAccount, create a +Secret of type `kubernetes.io/service-account-token` with an annotation +referencing the ServiceAccount, and the controller will update it with a +generated token: -secret.json: +Below is a sample configuration for such a Secret: -```json -{ - "kind": "Secret", - "apiVersion": "v1", - "metadata": { - "name": "mysecretname", - "annotations": { - "kubernetes.io/service-account.name": "myserviceaccount" - } - }, - "type": "kubernetes.io/service-account-token" -} +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecretname + annotations: + kubernetes.io/service-account.name: myserviceaccount +type: kubernetes.io/service-account-token ``` ```shell -kubectl create -f ./secret.json +kubectl create -f ./secret.yaml kubectl describe secret mysecretname ``` -#### To delete/invalidate a service account token +#### To delete/invalidate a ServiceAccount token Secret ```shell kubectl delete secret mysecretname ``` -### Service Account Controller +### ServiceAccount controller -Service Account Controller manages ServiceAccount inside namespaces, and ensures -a ServiceAccount named "default" exists in every active namespace. +A ServiceAccount controller manages the ServiceAccounts inside namespaces, and +ensures a ServiceAccount named "default" exists in every active namespace. From b04ff89c23d782e242021af0619a3ddc4c225205 Mon Sep 17 00:00:00 2001 From: Nate W Date: Tue, 27 Oct 2020 09:39:22 -0700 Subject: [PATCH 013/303] .editorconfig: turning off trim_trailing_whitespace for markdown files Adding *.md section to turn off trim_trailing_whitespace for .md files. (Fixes: https://github.com/kubernetes/website/issues/24731) Signed-off-by: Nate W --- .editorconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.editorconfig b/.editorconfig index e49c89c4e8..bc1dfe40c8 100644 --- a/.editorconfig +++ b/.editorconfig @@ -5,6 +5,9 @@ charset = utf-8 max_line_length = 80 trim_trailing_whitespace = true +[*.md] +trim_trailing_whitespace = false + [*.{css,html,js,json,sass,md,mmark,toml,yaml}] indent_style = space indent_size = 2 From 0b03d253e2bbbbaf77d8af0b0f9c25b9ccc05af1 Mon Sep 17 00:00:00 2001 From: "wangjibao.lc" Date: Fri, 30 Oct 2020 15:51:04 +0800 Subject: [PATCH 014/303] update broken link --- README-vi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-vi.md b/README-vi.md index 3a1ee99195..cd89b74725 100644 --- a/README-vi.md +++ b/README-vi.md @@ -15,7 +15,7 @@ Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách n * [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/) * [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Sử dụng các trang templates](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/) * [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/) From 0f4db0dc906818bca8fa5b6e31e571d05ce4f62a Mon Sep 17 00:00:00 2001 From: Mike Lundy Date: Fri, 30 Oct 2020 14:56:32 -0700 Subject: [PATCH 015/303] document HPA's implicit deactivation --- .../docs/tasks/run-application/horizontal-pod-autoscale.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 927c146cf5..b51ffc7ecb 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -433,7 +433,14 @@ behavior: selectPolicy: Disabled ``` +## Support for implicit maintenance-mode deactivation +Starting from v1.4, you can implicitly deactivate the HPA for a target without the +need to change the HPA configuration itself. If the target's desired replica count +is set to 0, and the HPA's minimum replica count is greater than 0, the HPA will +cease to adjust the target (and will set the `ScalingActive` Condition on itself +to `false`) until you reactivate it by manually adjusting the target's desired +replica count or HPA's minimum replica count. ## {{% heading "whatsnext" %}} From 862482e4d1ef52868ebb946b2a731181b46d2c9d Mon Sep 17 00:00:00 2001 From: Mike Lundy Date: Sat, 31 Oct 2020 12:00:00 -0700 Subject: [PATCH 016/303] Apply suggestions from code review Co-authored-by: Tim Bannister --- .../tasks/run-application/horizontal-pod-autoscale.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index b51ffc7ecb..ff16a13e74 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -433,12 +433,12 @@ behavior: selectPolicy: Disabled ``` -## Support for implicit maintenance-mode deactivation +## Implicit maintenance-mode deactivation -Starting from v1.4, you can implicitly deactivate the HPA for a target without the +You can implicitly deactivate the HPA for a target without the need to change the HPA configuration itself. If the target's desired replica count -is set to 0, and the HPA's minimum replica count is greater than 0, the HPA will -cease to adjust the target (and will set the `ScalingActive` Condition on itself +is set to 0, and the HPA's minimum replica count is greater than 0, the HPA +stops adjusting the target (and sets the `ScalingActive` Condition on itself to `false`) until you reactivate it by manually adjusting the target's desired replica count or HPA's minimum replica count. @@ -448,4 +448,3 @@ replica count or HPA's minimum replica count. * Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). * kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). - From 4450d7ecf436fff33e440db8e44b0212cb8e2fd5 Mon Sep 17 00:00:00 2001 From: "M. Habib Rosyad" Date: Sun, 1 Nov 2020 12:36:40 +0700 Subject: [PATCH 017/303] Improve maintainability of case studies styling for PT --- .../pt/case-studies/chinaunicom/index.html | 134 ++++++++---------- 1 file changed, 58 insertions(+), 76 deletions(-) diff --git a/content/pt/case-studies/chinaunicom/index.html b/content/pt/case-studies/chinaunicom/index.html index c3a1f81f8a..d01e01a1e9 100644 --- a/content/pt/case-studies/chinaunicom/index.html +++ b/content/pt/case-studies/chinaunicom/index.html @@ -1,96 +1,78 @@ --- title: Estudo de caso China Unicom - linkTitle: chinaunicom case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css -logo: chinaunicom_featured_logo.png -featured: true -weight: 1 -quote: > - O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo. +featured: false + +new_case_study_styles: true +heading_background: /images/case-studies/chinaunicom/banner1.jpg +heading_title_logo: /images/chinaunicom_logo.png +title_prefix: "ESTUDO DE CASO:" +subheading: > + China Unicom: Como o Kubernetes alavancou a utilização de recursos, aumentando sua eficiência operacional e menores custos em TI +case_study_details: + - Empresa: China Unicom + - Localização: Beijing, China + - Indústria: Telecom --- -
-

ESTUDO DE CASO:
China Unicom: Como o Kubernetes alavancou a utilização de recursos, aumentando sua eficiência operacional e menores custos em TI +

Desafio

-

+

A China Unicom é uma das três principais operadoras de telecomunicações da China e, para atender seus 300 milhões de usuários, a empresa administra vários data centers com milhares de servidores em cada um, usando Docker Contêiner, VMWare e OpenStack em sua infra-estrutura desde 2016. Infelizmente, "a taxa de utilização de recursos era relativamente baixa", diz Chengyu Zhang, líder do Grupo de Pesquisa e Desenvolvimento de Tecnologia de Plataforma, "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos". Outrora uma empresa totalmente estatal, a China Unicom, nos últimos anos, obteve investimentos privados da BAT (Baidu, Alibaba, Tencent) e JD.com, e agora está se concentrando no desenvolvimento interno usando tecnologia open source, ao invés de produtos comerciais. Como tal, a equipe do China Unicom Lab de Zhang começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.

-
+

Solução

-
- Empresa  China Unicom     Localização  Beijing, China     Indústria  Telecom -
+

Por causa de seu crescimento rápido e comunidade madura de código aberto, o Kubernetes foi uma escolha natural para a China Unicom. A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo." A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd.

-
-
-
-
-

Desafio

- A China Unicom é uma das três principais operadoras de telecomunicações da China e, para atender seus 300 milhões de usuários, a empresa administra vários data centers com milhares de servidores em cada um, usando Docker Contêiner, VMWare e OpenStack em sua infra-estrutura desde 2016. Infelizmente, "a taxa de utilização de recursos era relativamente baixa", diz Chengyu Zhang, líder do Grupo de Pesquisa e Desenvolvimento de Tecnologia de Plataforma, "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos". Outrora uma empresa totalmente estatal, a China Unicom, nos últimos anos, obteve investimentos privados da BAT (Baidu, Alibaba, Tencent) e JD.com, e agora está se concentrando no desenvolvimento interno usando tecnologia open source, ao invés de produtos comerciais. Como tal, a equipe do China Unicom Lab de Zhang começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem. -

-

Solução

- Por causa de seu crescimento rápido e comunidade madura de código aberto, o Kubernetes foi uma escolha natural para a China Unicom. A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo." A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd. -

Impacto

- Na China Unicom, o Kubernetes melhorou a eficiência operacional e de desenvolvimento. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à autocorreção e à escalabilidade, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas. Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo". -
+

Na China Unicom, o Kubernetes melhorou a eficiência operacional e de desenvolvimento. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à autocorreção e à escalabilidade, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas. Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".

-
-
-
-
- "O Kubernetes melhorou nossa experiência usando a infraestrutura em nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo." -

- Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom -
-
-
-
-

Com mais de 300 milhões de usuários, a China Unicom é uma das três principais operadoras de telecomunicações do país.

+{{< case-studies/quote author="Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom" >}} +"O Kubernetes melhorou nossa experiência usando a infraestrutura em nuvem. Atualmente, não há tecnologia alternativa que possa substituí-lo." +{{< /case-studies/quote >}} - Nos bastidores, a empresa administra vários datacenters com milhares de servidores em cada um, usando contêineres Docker, infra-estrutura VMWare e OpenStack desde 2016. Infelizmente, "a taxa de utilização de recursos foi relativamente baixa", diz Chengyu Zhang, líder de pesquisa e desenvolvimento de plataformas tecnológicas. "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos".

-  A equipe de Zhang, responsável por novas tecnologias, pesquisa e desenvolvimento e plataformas, decidiu encontrar uma solução de gerenciamento de TI. Anteriormente uma empresa totalmente estatal, a China Unicom tem, nos últimos anos, feito investimentos privados da BAT (Baidu, Alibaba, Tencent) e da JD.com, e agora está se concentrando no desenvolvimento local usando tecnologia open source, ao invés de produtos comerciais. Por esse motivo, a equipe começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem. +{{< case-studies/lead >}} +Com mais de 300 milhões de usuários, a China Unicom é uma das três principais operadoras de telecomunicações do país. +{{< /case-studies/lead >}} -
-
-
-
- "Nós nunca poderíamos imaginar que alcançaríamos essa escalabilidade em tão pouco tempo."

- Chengyu Zhang, Líder do Grupo de Tecnologia de Plataforma de Pesquisa e Desenvolvimento, China Unicom +

Nos bastidores, a empresa administra vários datacenters com milhares de servidores em cada um, usando contêineres Docker, infra-estrutura VMWare e OpenStack desde 2016. Infelizmente, "a taxa de utilização de recursos foi relativamente baixa", diz Chengyu Zhang, líder de pesquisa e desenvolvimento de plataformas tecnológicas. "e não tínhamos uma plataforma de nuvem para acomodar nossas centenas de aplicativos".

-
-
-
-
- Embora a China Unicom já estivesse usando o Mesos para um sistema central de operadoras de telecomunicações, a equipe sentiu que o Kubernetes era uma escolha natural para a nova plataforma de nuvem. "A principal razão foi que tem uma comunidade madura", diz Zhang. "Ela cresce muito rapidamente e, portanto, podemos aprender muito com as melhores práticas das outras pessoas". A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd.

-  A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. Os desenvolvedores da China Unicom podem facilmente aproveitar a tecnologia por meio de APIs, sem fazer o trabalho de desenvolvimento por conta própria. A plataforma de nuvem fornece 20 a 30 serviços conectados à plataforma PaaS de data center da empresa, além de oferecer suporte a análises de big data para usuários internos nas filiais das 31 províncias da China.

-  "O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo." -
-
-
-
- "Essa tecnologia é relativamente complicada, mas quando os desenvolvedores se acostumarem, eles poderão desfrutar de todos os benefícios."

- Jie Jia , Membro da Plataforma de Tecnologia de I & D, China Unicom -
-
+

A equipe de Zhang, responsável por novas tecnologias, pesquisa e desenvolvimento e plataformas, decidiu encontrar uma solução de gerenciamento de TI. Anteriormente uma empresa totalmente estatal, a China Unicom tem, nos últimos anos, feito investimentos privados da BAT (Baidu, Alibaba, Tencent) e da JD.com, e agora está se concentrando no desenvolvimento local usando tecnologia open source, ao invés de produtos comerciais. Por esse motivo, a equipe começou a procurar por um framework de orquestração que fosse de código aberto para sua infraestrutura de nuvem.

-
-
- Na verdade, o Kubernetes aumentou a eficiência operacional e de desenvolvimento na China Unicom. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à auto-correção e escalabilidade do Kubernetes, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas".

-  Com os ganhos que a China Unicom experimentou com o Kubernetes, Zhang e sua equipe estão ansiosos para devolver à comunidade. Isso começa com a participação em encontros e conferências, e oferecendo conselhos para outras empresas que estão considerando um caminho semelhante. "Especialmente para as empresas que têm um sistema tradicional de computação em nuvem, eu realmente recomendo que elas se juntem à comunidade de computação nativa da nuvem", diz Zhang. -
+{{< case-studies/quote + image="/images/case-studies/chinaunicom/banner3.jpg" + author="Chengyu Zhang, Líder do Grupo de Pesquisa e Desenvolvimento em Tecnologia de Plataforma, China Unicom" +>}} +"Nós nunca poderíamos imaginar que alcançaríamos essa escalabilidade em tão pouco tempo." +{{< /case-studies/quote >}} -
-
- "As empresas podem usar os serviços gerenciados oferecidos por empresas como a Rancher, porque eles já personalizaram essa tecnologia, e você pode aproveitar essa tecnologia com facilidade."

- Jie Jia, membro da Plataforma de Tecnologia de P&D, China Unicom
-
+

Embora a China Unicom já estivesse usando o Mesos para um sistema central de operadoras de telecomunicações, a equipe sentiu que o Kubernetes era uma escolha natural para a nova plataforma de nuvem. "A principal razão foi que tem uma comunidade madura", diz Zhang. "Ela cresce muito rapidamente e, portanto, podemos aprender muito com as melhores práticas das outras pessoas". A China Unicom também usa o Istio para sua estrutura de microsserviço, Envoy, CoreDNS e Fluentd.

-
- Jie Jia, membro da equipe de Tecnologia de P&D da Plataforma, acrescenta que, embora "essa tecnologia seja relativamente complicada, desde que os desenvolvedores se acostumem a ela, eles poderão desfrutar de todos os benefícios". E Zhang ressalta que, em sua própria experiência com a nuvem de máquinas virtuais, "o Kubernetes e essas tecnologias nativas de nuvem são relativamente mais simples".

-  Além disso, "as empresas podem usar os serviços gerenciados oferecidos por empresas como Rancher, porque eles já personalizaram essa tecnologia", diz Jia. "Você pode facilmente aproveitar essa tecnologia".

-  Olhando para o futuro, a China Unicom planeja desenvolver mais aplicativos no Kubernetes, com foco em big data e aprendizado de máquina. A equipe continua a otimizar a plataforma de nuvem que construiu e espera passar no teste de conformidade para se juntar ao programa de Certificação Kubernetes com 32 distros e plataformas compatíveis. Eles também esperam, um dia, contribuir com o código para a comunidade.

-  Se isso soa ambicioso, é porque os resultados que eles obtiveram ao adotar o Kubernetes foram além de suas maiores expectativas. Zhang diz: "Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo". -
-
- - +

A plataforma de nuvem habilitada para Kubernetes da empresa agora hospeda 50 microsserviços e todo o novo desenvolvimento daqui para frente. Os desenvolvedores da China Unicom podem facilmente aproveitar a tecnologia por meio de APIs, sem fazer o trabalho de desenvolvimento por conta própria. A plataforma de nuvem fornece 20 a 30 serviços conectados à plataforma PaaS de data center da empresa, além de oferecer suporte a análises de big data para usuários internos nas filiais das 31 províncias da China.

+ +

"O Kubernetes melhorou nossa experiência usando a infraestrutura de nuvem", diz Zhang. "Atualmente, não há tecnologia alternativa que possa substituí-lo."

+ +{{< case-studies/quote + image="/images/case-studies/chinaunicom/banner4.jpg" + author="Jie Jia, Membro da Plataforma de Tecnologia de I & D, China Unicom" +>}} +"Essa tecnologia é relativamente complicada, mas quando os desenvolvedores se acostumarem, eles poderão desfrutar de todos os benefícios." +{{< /case-studies/quote >}} + +

Na verdade, o Kubernetes aumentou a eficiência operacional e de desenvolvimento na China Unicom. A utilização de recursos aumentou de 20 a 50%, diminuindo os custos de infraestrutura de TI, e o tempo de implantação passou de algumas horas para 5 a 10 minutos. "Isso se deve principalmente à auto-correção e escalabilidade do Kubernetes, para que possamos aumentar nossa eficiência em operação e manutenção", diz Zhang. "Por exemplo, atualmente temos apenas cinco pessoas mantendo nossos múltiplos sistemas".

+ +

Com os ganhos que a China Unicom experimentou com o Kubernetes, Zhang e sua equipe estão ansiosos para devolver à comunidade. Isso começa com a participação em encontros e conferências, e oferecendo conselhos para outras empresas que estão considerando um caminho semelhante. "Especialmente para as empresas que têm um sistema tradicional de computação em nuvem, eu realmente recomendo que elas se juntem à comunidade de computação nativa da nuvem", diz Zhang.

+ +{{< case-studies/quote author="Jie Jia, Membro da Plataforma de Tecnologia de I & D, China Unicom" >}} +"As empresas podem usar os serviços gerenciados oferecidos por empresas como a Rancher, porque eles já personalizaram essa tecnologia, e você pode aproveitar essa tecnologia com facilidade." +{{< /case-studies/quote >}} + +

Jie Jia, membro da equipe de Tecnologia de P&D da Plataforma, acrescenta que, embora "essa tecnologia seja relativamente complicada, desde que os desenvolvedores se acostumem a ela, eles poderão desfrutar de todos os benefícios". E Zhang ressalta que, em sua própria experiência com a nuvem de máquinas virtuais, "o Kubernetes e essas tecnologias nativas de nuvem são relativamente mais simples".

+ +

Além disso, "as empresas podem usar os serviços gerenciados oferecidos por empresas como Rancher, porque eles já personalizaram essa tecnologia", diz Jia. "Você pode facilmente aproveitar essa tecnologia".

+ +

Olhando para o futuro, a China Unicom planeja desenvolver mais aplicativos no Kubernetes, com foco em big data e aprendizado de máquina. A equipe continua a otimizar a plataforma de nuvem que construiu e espera passar no teste de conformidade para se juntar ao programa de Certificação Kubernetes com 32 distros e plataformas compatíveis. Eles também esperam, um dia, contribuir com o código para a comunidade.

+ +

Se isso soa ambicioso, é porque os resultados que eles obtiveram ao adotar o Kubernetes foram além de suas maiores expectativas. Zhang diz: "Nós nunca poderíamos imaginar que podemos alcançar essa escalabilidade em tão pouco tempo".

From 072f8a7dcb1bc8e3d7aa067dc91c16a978fb7edf Mon Sep 17 00:00:00 2001 From: "M. Habib Rosyad" Date: Sun, 1 Nov 2020 15:27:42 +0700 Subject: [PATCH 018/303] Improve maintainability of case studies styling for JA --- content/ja/case-studies/appdirect/index.html | 112 +++++++------ .../ja/case-studies/chinaunicom/index.html | 134 +++++++-------- content/ja/case-studies/nav/index.html | 129 +++++++-------- content/ja/case-studies/nordstrom/index.html | 153 +++++++----------- content/ja/case-studies/sos/index.html | 134 +++++++-------- content/ja/case-studies/spotify/index.html | 144 ++++++----------- 6 files changed, 345 insertions(+), 461 deletions(-) diff --git a/content/ja/case-studies/appdirect/index.html b/content/ja/case-studies/appdirect/index.html index 0be120c3b5..a5ef3a354b 100644 --- a/content/ja/case-studies/appdirect/index.html +++ b/content/ja/case-studies/appdirect/index.html @@ -1,70 +1,84 @@ --- title: AppDirect ケーススタディ - linkTitle: AppDirect case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css logo: appdirect_featured_logo.png featured: true weight: 4 quote: > 私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。 + +new_case_study_styles: true +heading_background: /images/case-studies/appdirect/banner1.jpg +heading_title_logo: /images/appdirect_logo.png +title_prefix: "ケーススタディ：" +subheading: > + AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか +case_study_details: + - 企業名: AppDirect + - 所在地: カリフォルニア州サンフランシスコ + - 業界: ソフトウェア --- -
-

ケーススタディ：
AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか
+

課題

-

+

AppDirect はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。そのため、提供までのパイプラインにボトルネックがあったのです。」これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。

-
+

ソリューション

-
企業名  AppDirect     所在地  カリフォルニア州サンフランシスコ     業界 ソフトウェア -
+

Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」彼らは、2016年初めKubernetes の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のためにPrometheus モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS 上や世界中のオンプレミス環境で展開しています。

-
-
-
-
-

課題

AppDirect はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。 -そのため、提供までのパイプラインにボトルネックがあったのです。」 -これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。 -

ソリューション

Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」 -彼らは、2016年初めKubernetes の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のためにPrometheus -モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS 上や世界中のオンプレミス環境で展開しています。

インパクト

Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。 -彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。 -新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。 -こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのにJira のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。 -以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。 -また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。 -
-
-
-
-
「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
-
-
-
-

AppDirect は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。


2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」

これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、Node.js に Spring Boot Javaといった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。
-
-
-
「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」

- AppDirect ソフトウェア開発者　Alexandre Gervais
-
-
-
Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。

Lacerteのグループは運用チームと連携することで同社の AWSのインフラにより多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で Chef やTerraform によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分でKopsを使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。

今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。

Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 Jiraのチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。 -
-
-
-
「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
-
+

インパクト

+ +

Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのにJira のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。

+ +{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}} +「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +AppDirect は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。 +{{< /case-studies/lead >}} + +

2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」

+ +

これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、Node.js に Spring Boot Javaといった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。

+ +{{< case-studies/quote + image="/images/case-studies/appdirect/banner3.jpg" + author="AppDirect ソフトウェア開発者　Alexandre Gervais" +>}} +「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」 +{{< /case-studies/quote >}} + +

Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。

+ +

Lacerteのグループは運用チームと連携することで同社の AWSのインフラにより多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で Chef やTerraform によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分でKopsを使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。

+ +

今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。

+ +

Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 Jiraのチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。

+ +{{< case-studies/quote + image="/images/case-studies/appdirect/banner4.jpg" + author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" +>}} +「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」 +{{< /case-studies/quote >}}
-
さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました

AppDirectのクラウドネイティブなスタックにはgRPC、Fluentdも含まれていて、そして今このチームはOpenCensusの立ち上げに取り組んでいるところです。このプラットフォームはすでにPrometheus で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境ではSlack メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」
+

さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました

-
-
「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte
-
+

AppDirectのクラウドネイティブなスタックにはgRPC、Fluentdも含まれていて、そして今このチームはOpenCensusの立ち上げに取り組んでいるところです。このプラットフォームはすでにPrometheus で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境ではSlack メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」

-
もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」

Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」
-
+{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}} +「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 +{{< /case-studies/quote >}} + +

もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」

+ +

エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」

+ +

Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」

diff --git a/content/ja/case-studies/chinaunicom/index.html b/content/ja/case-studies/chinaunicom/index.html index 622820ada0..1f3fff3cee 100644 --- a/content/ja/case-studies/chinaunicom/index.html +++ b/content/ja/case-studies/chinaunicom/index.html @@ -1,104 +1,78 @@ --- -title: China Unicom Case Study - +title: China Unicom ケーススタディ linkTitle: chinaunicom case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css -logo: chinaunicom_featured_logo.png -featured: true -weight: 1 -quote: > - Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。 +featured: false + +new_case_study_styles: true +heading_background: /images/case-studies/chinaunicom/banner1.jpg +heading_title_logo: /images/chinaunicom_logo.png +title_prefix: "ケーススタディ：" +subheading: > + Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。 +case_study_details: + - 企業名: China Unicom + - 所在地: 中国、北京 + - 業界: テレコム --- -
-

ケーススタディ：
China Unicom社：KubernetesによるITコスト削減と効率性向上をいかにして実現したか
+

課題

-

+

China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWare、OpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。

-
+

ソリューション

-
- 企業名  China Unicom     所在地 中国、北京     業界 テレコム -
+

急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、Istio、 Envoy、 CoreDNS、そしてFluentdも活用しています。

-
-
-
-
-

課題

- China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 VMWare、OpenStackのインフラやDockerによるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。 -

- -

ソリューション

- 急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、Istio、 Envoy、 CoreDNS、そしてFluentdも活用しています。 -

インパクト

- KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。 -リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。 -
+

KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。

-
-
-
-
- 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」 -
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー -
-
-
-
-

China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。

+{{< case-studies/quote author="Chengyu Zhang、China Unicom プラットフォーム技術R&D グループリーダー" >}} +「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」 +{{< /case-studies/quote >}} - その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」 -

- そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。 -
-
-
-
- 「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
- Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー +{{< case-studies/lead >}} +China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。 +{{< /case-studies/lead >}} -
-
-
-
- China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。

+

その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」

- 同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。

+

そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。

- 「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」 +{{< case-studies/quote + image="/images/case-studies/chinaunicom/banner3.jpg" + author="Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー" +>}} +「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」 +{{< /case-studies/quote >}} -
-
-
-
- 「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」

- Jie Jia、China Unicom プラットフォーム技術 R&D -
-
+

China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。

-
-
- 事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」

- China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。 -
+

同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。

-
-
-「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

- Jie Jia、China Unicom プラットフォーム技術 R&D
-
+

「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」

-
- プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。

- 「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

+{{< case-studies/quote + image="/images/case-studies/chinaunicom/banner4.jpg" + author="Jie Jia、China Unicom プラットフォーム技術 R&D" +>}} +「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」 +{{< /case-studies/quote >}} - 今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。

+

事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」

- それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」 +

China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。

-
-
- - +{{< case-studies/quote author="Jie Jia、China Unicom プラットフォーム技術 R&D" >}} +「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」 +{{< /case-studies/quote >}} + +

プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。

+ +

「企業は Rancher のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」

+ +

今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。

+ +

それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」

diff --git a/content/ja/case-studies/nav/index.html b/content/ja/case-studies/nav/index.html index c0e9afa890..1c1f34c78e 100644 --- a/content/ja/case-studies/nav/index.html +++ b/content/ja/case-studies/nav/index.html @@ -1,93 +1,82 @@ --- -title: Navケーススタディ +title: Nav ケーススタディ linkTitle: Nav case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css -logo: nav_featured_logo.png -featured: true -weight: 3 +featured: false quote: > - コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。 + コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。 + +new_case_study_styles: true +heading_background: /images/case-studies/nav/banner1.jpg +heading_title_logo: /images/nav_logo.png +title_prefix: "ケーススタディ：" +subheading: > + スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか +case_study_details: + - 企業名: Nav + - 所在地: ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ + - 業界: 事業者向け金融サービス --- -
-

ケーススタディ：
スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか

+

課題

-
+

2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」

-
- 企業名  Nav     所在地  ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ     業界  事業者向け金融サービス -
- -
-
-
-
-

-

課題

-2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」 -

ソリューション

-数多くのオーケストレーション ソリューションを評価した結果、Navチームは AWS上で稼働する Kubernetesを採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」 + +

数多くのオーケストレーション ソリューションを評価した結果、Navチームは AWS上で稼働する Kubernetesを採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

インパクト

-4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。 -
-
-
+

4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。

-
-
- -

+{{< case-studies/quote author="Travis Jeppson、Nav エンジニアリング ディレクター" >}} + +
「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」 -

- Travis Jeppson、Nav エンジニアリング ディレクター
-
-
-
-

2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。

-数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」 -

- こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」 +{{< /case-studies/quote >}} -
-
-
-
「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」

- Travis Jeppson、Nav エンジニアリングディレクター
+{{< case-studies/lead >}} +2012年に設立された Navは、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。 +{{< /case-studies/lead >}} +

数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」

-
-
-
Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。

- 数多くのオーケストレーションソリューションを評価した結果、Navチームは AWSでのKubernetes 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

- Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために Kubespray を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」 -
-
-
-
-「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」

- Travis Jeppson、Nav エンジニアリングディレクター -
-
+

こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」

-
+{{< case-studies/quote + image="/images/case-studies/nav/banner3.jpg" + author="Travis Jeppson、Nav エンジニアリングディレクター" +>}} +「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」 +{{< /case-studies/quote >}} -
-この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。 -そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために GitLabにリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、kubectlを用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」

- マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。

- また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、Twistlockツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。 -
+

Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。

-
-
「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」

- Travis Jeppson、Nav エンジニアリング ディレクター
-
+

数多くのオーケストレーションソリューションを評価した結果、Navチームは AWSでのKubernetes 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」

-
- Kubernetesが導入された中、Navチームは Prometheusを採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」

- これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らはEnvoy、 OpenTracing、そして Jaegerを検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」

- もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」 +

Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために Kubespray を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」

-
-
+{{< case-studies/quote + image="/images/case-studies/nav/banner4.jpg" + author="Travis Jeppson、Nav エンジニアリングディレクター" +>}} +「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」 +{{< /case-studies/quote >}} + +

この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために GitLabにリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、kubectlを用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」

+ +

マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。

+ +

また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、Twistlockツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。

+ +{{< case-studies/quote author="Travis Jeppson、Nav エンジニアリング ディレクター" >}} +「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」 +{{< /case-studies/quote >}} + +

Kubernetesが導入された中、Navチームは Prometheusを採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」

+ +

これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らはEnvoy、 OpenTracing、そして Jaegerを検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」

+ +

もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」

diff --git a/content/ja/case-studies/nordstrom/index.html b/content/ja/case-studies/nordstrom/index.html index b6f77e9003..ec757ca23c 100644 --- a/content/ja/case-studies/nordstrom/index.html +++ b/content/ja/case-studies/nordstrom/index.html @@ -2,105 +2,76 @@ title: Nordstrom ケーススタディ case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css + +new_case_study_styles: true +heading_background: /images/case-studies/nordstrom/banner1.jpg +heading_title_logo: /images/nordstrom_logo.png +title_prefix: "ケーススタディ：" +subheading: > + 厳しい小売環境下で数百万ドルのコスト削減を実現 +case_study_details: + - 企業名: Nordstrom + - 所在地: シアトル、ワシントン + - 業界: 小売り --- -
-

ケーススタディ:
厳しい小売環境下で数百万ドルのコスト削減を実現 +

課題

+ +

NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。

+ +

解決策

+ +

4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、KubernetesでオーケストレーションされたDockerコンテナを採用しました。

+ +

影響

+ +

Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」

+ +{{< case-studies/quote author="Nordstrom社シニアエンジニア Dhawal Patel" >}} +私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。 +{{< /case-studies/quote >}} + +

5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者としてNordstromに入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。

+ +

DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」

+ +

同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。

+ +

開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームはChefを選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」

+ +

しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。

+ +{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}} +「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」 +{{< /case-studies/quote >}} + +

「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」

+ +

Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。

+ +

Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」

+ +

参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」

+ +{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}} +「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 +{{< /case-studies/quote >}} -

+

これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のためのPrometheusとGrafanaフロントエンドを組み合わせました。また、Fluentdを使用してログをElasticsearchにプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。

-
+

現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」

-
- 企業名  Nordstrom     所在地  シアトル、ワシントン     業界  小売り -
+

Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。

-
-
-
-
-

課題

- NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。 -
-

解決策

- 4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、KubernetesでオーケストレーションされたDockerコンテナを採用しました。 -
+{{< case-studies/quote >}} +「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 +{{< /case-studies/quote >}} +

スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」

-
+

Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」

-
+

そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」

-

影響

- Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」 -
-
-
-
-
- 私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。 -

-Nordstrom社シニアエンジニア Dhawal Patel -
-
-
-
- 5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者としてNordstromに入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。 -

- DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」 -

- 同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。 -

- 開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームはChefを選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」 -

しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。 - -
-
-
-
- 「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」 -
-
-
-
- -「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」 -

-Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。 -Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」 -

-参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 -
-
-
-
- 「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」 -
-
- -
-
- これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のためのPrometheusとGrafanaフロントエンドを組み合わせました。また、Fluentdを使用してログをElasticsearchにプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。 -

-現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」 -

-Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。 -
- -
-
- 「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 -
-
- -
- スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」 -

- Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」 - そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」 -

- この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」 - -
-
+

この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」

diff --git a/content/ja/case-studies/sos/index.html b/content/ja/case-studies/sos/index.html index d893f6a9b3..c63fa4ab51 100644 --- a/content/ja/case-studies/sos/index.html +++ b/content/ja/case-studies/sos/index.html @@ -3,108 +3,82 @@ title: SOS International ケーススタディ linkTitle: SOS International case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css logo: sos_featured_logo.png + +new_case_study_styles: true +heading_background: /images/case-studies/sos/banner1.jpg +heading_title_logo: /images/sos_logo.png +title_prefix: "ケーススタディ：" +subheading: > + SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供 +case_study_details: + - 企業名: SOS International + - 所在地: フレゼレクスベア、デンマーク + - 業界: 医療および旅行支援 --- +

課題

-
-

ケーススタディ:
SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供 +

SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」

-

+

ソリューション

-
+

標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。RedHat OpenShiftはSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。

-
- 企業名  SOS International     所在地  フレゼレクスベア、デンマーク -     業界  医療および旅行支援 -
- -
-
-
-
-

課題

- SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては -3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」 - - -

-

ソリューション

- 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。RedHat OpenShiftはSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。 -

影響

- Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 -
-
-
-
-
- 「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。 -

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen -
-
-
-
-

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

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

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

- Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」 +

Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」

+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}} +「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。」 +{{< /case-studies/quote >}} -
-
-
-
- 「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」 +{{< case-studies/lead >}} +SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。 +{{< /case-studies/lead >}} -

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen +

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

-
-
-
-
- Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。

+

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

- 技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」

+

Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」

-プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。 -
-
-
-
- 「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 -

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen -
-
+{{< case-studies/quote + image="/images/case-studies/sos/banner3.jpg" + author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" +>}} +「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」 +{{< /case-studies/quote >}} -
-
- プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。

+

Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。

- SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」

+

技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」

- しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。

+

プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。

- さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 +{{< case-studies/quote + image="/images/case-studies/sos/banner4.jpg" + author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" +>}} +「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」 +{{< /case-studies/quote >}} -
+

プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。

-
-
- 「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」 -

- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen
-
+

SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」

-
- SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」

+

しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。

- SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」

+

さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」

- 代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」

+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}} +「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」 +{{< /case-studies/quote >}} - Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」 -
-
+

SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」

+ +

SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」

+ +

代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」

+ +

Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」

diff --git a/content/ja/case-studies/spotify/index.html b/content/ja/case-studies/spotify/index.html index 49d929995d..09a82b5fdb 100644 --- a/content/ja/case-studies/spotify/index.html +++ b/content/ja/case-studies/spotify/index.html @@ -1,120 +1,82 @@ --- -title: Spotifyケーススタディ -linkTitle: Spotify +title: Spotify ケーススタディ +linkTitle: Spotify case_study_styles: true cid: caseStudies -css: /css/style_case_studies.css -logo: spotify_featured_logo.png -featured: true -weight: 2 +featured: false quote: > - Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。 + Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。 + +new_case_study_styles: true +heading_background: /images/case-studies/spotify/banner1.jpg +heading_title_text: Spotify +title_prefix: "ケーススタディ：" +subheading: > + Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています +case_study_details: + - 企業名: Spotify + - 所在地: グローバル + - 業界: エンターテイメント --- -
-

ケーススタディ：Spotify
Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています +

課題

-

+

2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、Heliosという自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。

-
+

ソリューション

-
- 企業名  Spotify     所在地  グローバル     業界  エンターテイメント -
- -
-
-
-
-

課題

- 2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、Heliosという自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。 - -

-

ソリューション

- 「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。 +

「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。

インパクト

- 2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。 - -
-
-
-
-
- 「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」

- Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti -
-
-
-
-

「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。 -2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。

-

- マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」

しかし、2017年の終わりまでには、「小さなチームがHeliosの機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。 +

2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。

+{{< case-studies/quote author="Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti" >}} +「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」 +{{< /case-studies/quote >}} -
-
-
-
- 「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」

- Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky +{{< case-studies/lead >}} +「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。 +{{< /case-studies/lead >}} -
-
-
-
- もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」 - -

+

マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」

-チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。 +

しかし、2017年の終わりまでには、「小さなチームがHeliosの機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。

-

-マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」 -

-今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。 +{{< case-studies/quote + image="/images/case-studies/spotify/banner3.jpg" + author="Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky" +>}} +「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」 +{{< /case-studies/quote >}} -「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。 +

もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」

-Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。 +

チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。

+

マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」

-
-
-
-
- 「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」

- Spotify、Spotifyエンジニア、James Wen -
-
+

今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。

-
-
- Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。 -

-Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」 -

-またSpotifyはgRPCとenvoyを使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」 +{{< case-studies/quote + image="/images/case-studies/spotify/banner4.jpg" + author="Spotify、Spotifyエンジニア、James Wen" +>}} +「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」 +{{< /case-studies/quote >}} +

Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。

-
+

Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」

-
-
- 「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」

- Spotify、サイト・リライアビリティ・エンジニア、James Wen
-
+

またSpotifyはgRPCとenvoyを使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」

+{{< case-studies/quote author="Spotify、サイト・リライアビリティ・エンジニア、James Wen" >}} +「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」 +{{< /case-studies/quote >}} -
- どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」 +

どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」

-

-チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです - CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。 +

チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです - CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。

-

-SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」 - - -
-
- - +

SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」

From 60990a4e0f7bc0f3e3badfd5b98ef812fcf18a7d Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 2 Nov 2020 13:30:34 +0900 Subject: [PATCH 019/303] Apply suggestions from code review Co-authored-by: nasa9084 --- .../services-networking/endpoint-slices.md | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md index 8d4e124855..e09993b5ea 100644 --- a/content/ja/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md @@ -8,19 +8,19 @@ weight: 15 {{< feature-state for_k8s_version="v1.17" state="beta" >}} -*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能なEndpointの代わりとなるものです。 +*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能な、Endpointの代わりとなるものです。 ## 動機 -Endpoints APIは、Kubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。 +Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。 Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。 ## EndpointSliceリソース {#endpointslice-resource} -Kubernetes内では、EndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceには、Serviceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceは、ネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。 @@ -47,13 +47,13 @@ endpoints: topology.kubernetes.io/zone: us-west2-a ``` -デフォルトでは、EndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceは、EndpointとServiceが1対1対応になり、性能は変わらないはずです。 +デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。 -EndpointSliceは、内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。 +EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。 ### アドレスの種類 -EndpointSliceは、次の3種類のアドレスをサポートします。 +EndpointSliceは次の3種類のアドレスをサポートします。 * IPv4 * IPv6 @@ -61,49 +61,48 @@ EndpointSliceは、次の3種類のアドレスをサポートします。 ### トポロジー -EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合には、EndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。 +EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。 * `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。 * `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。 * `topology.kubernetes.io/region` - このエンドポイントが存在するリージョン。 -これらのラベルの値は、スライス内の各エンドポイントと関連するリソースから継承したものです。hostnameラベルは、対応するPod上のNodeNameフィールドの値を表します。zoneとregionラベルは、対応するNode上の同じ名前のラベルの値を表します。 +これらのラベルの値はスライス内の各エンドポイントと関連するリソースから継承したものです。hostnameラベルは対応するPod上のNodeNameフィールドの値を表します。zoneとregionラベルは対応するNode上の同じ名前のラベルの値を表します。 ### 管理 -EndpointSliceは、デフォルトではEndpointSliceコントローラによって作成・管理されます。EndpointSliceには、他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 +EndpointSliceはデフォルトではEndpointSliceコントローラによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 ### 所有権 -ほとんどのユースケースでは、EndpointSliceは、対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと、`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。 +ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。 ## EndpointSliceコントローラー -EndpointSliceコントローラーは、対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーは、セレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceは、Serviceセレクターに一致するPodのIPを表します。 +EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。 ### EndpointSliceのサイズ -デフォルトでは、それぞれのEndpointSliceのサイズの上限は、100のEndpointsまでに制限されています。この制限は、{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。 +デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。 ### EndpointSliceの分散 -それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これは、サービスの部分集合がEndpointsにグループ化される場合と同様です。 +それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。 -コントローラーは、EndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。 +コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。 1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。 2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。 3. まだ追加するべき新しいエンドポイントが残っていた場合、これまで変更されなかったスライスに追加を試み、その後、新しいスライスを作成する。 -ここで重要なのは、3番目のステップでEndpointSliceを完全に分散させることよりも、EndpointSliceの更新を制限することを優先していることです。たとえば、もし新しい追加するべきエンドポイントが10個あり、2つのEndpointSliceにそれぞれ5個の空きがあった場合、このアプローチでは、2つの既存のEndpointSliceを充填する代わりに、新しいEndpointSliceが作られます。言い換えれば、1つのEndpointSliceを作成する方が、複数のEndpointSliceを更新するよりも好ましいということです。 +ここで重要なのは、3番目のステップでEndpointSliceを完全に分散させることよりも、EndpointSliceの更新を制限することを優先していることです。たとえば、もし新しい追加するべきエンドポイントが10個あり、2つのEndpointSliceにそれぞれ5個の空きがあった場合、このアプローチでは2つの既存のEndpointSliceを充填する代わりに、新しいEndpointSliceが作られます。言い換えれば、1つのEndpointSliceを作成する方が複数のEndpointSliceを更新するよりも好ましいということです。 各Node上で実行されているkube-proxyはEndpointSliceを監視しており、EndpointSliceに加えられた変更はクラスター内のすべてのNodeに送信されるため、比較的コストの高い処理になります。先ほどのアプローチは、たとえ複数のEndpointSliceが充填されない結果となるとしても、すべてのNodeへ送信しなければならない変更の数を抑制することを目的としています。 -現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントが、すべて置換されるためです。 +現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。 ## {{% heading "whatsnext" %}} * [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices) * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む - From dba15377f22c9e653ddda32232876f66376cb4a5 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 2 Nov 2020 14:49:24 +0900 Subject: [PATCH 020/303] =?UTF-8?q?Replace=20'=E3=82=B3=E3=83=B3=E3=83=88?= =?UTF-8?q?=E3=83=AD=E3=83=BC=E3=83=A9'=20with=20'=E3=82=B3=E3=83=B3?= =?UTF-8?q?=E3=83=88=E3=83=AD=E3=83=BC=E3=83=A9=E3=83=BC'.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/services-networking/endpoint-slices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md index e09993b5ea..5a678baec7 100644 --- a/content/ja/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md @@ -71,7 +71,7 @@ EndpointSliceに属する各エンドポイントは、関連するトポロジ ### 管理 -EndpointSliceはデフォルトではEndpointSliceコントローラによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 +EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 ### 所有権 From 674e1ee90f60b02358c39bc6606c734ef67c7b36 Mon Sep 17 00:00:00 2001 From: Benjamin Elder Date: Mon, 2 Nov 2020 13:42:43 -0800 Subject: [PATCH 021/303] fix download link without comment on the article, addressing https://github.com/kubernetes/kubernetes/issues/96086 :upside_down_face: --- content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md index 42b6a3c5a0..0a84075aaf 100644 --- a/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md +++ b/content/en/blog/_posts/2020-05-21-wsl2-dockerdesktop-k8s.md @@ -153,7 +153,7 @@ And as sources are always important to mention, we will follow (partially) the h ```bash # Download the latest version of KinD -curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-$(uname)-amd64 +curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.7.0/kind-linux-amd64 # Make the binary executable chmod +x ./kind # Move the binary to your executable path From d1faa62d4198a88e929754bb6e3f22dc91e699f6 Mon Sep 17 00:00:00 2001 From: keita mochizuki <37737691+mochizuki875@users.noreply.github.com> Date: Sun, 16 Aug 2020 00:28:06 +0900 Subject: [PATCH 022/303] Fix -apiserver-advertise-address Fix --apiserver-advertize-address= to --apiserver-advertise-address=. --- .../tools/kubeadm/create-cluster-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index c0156a4e6f..9c096a6698 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -63,7 +63,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。 1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。 1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。 1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。 -1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。 +1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。 コントロールプレーンノードを初期化するには、次のコマンドを実行します。 From dd02880d0cbbb25f39657964d680c98767289862 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 19 Aug 2020 06:06:16 +0900 Subject: [PATCH 023/303] Update tasks/tools/_index.md from en/ directory. --- content/ja/docs/tasks/tools/_index.md | 37 +++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md index bad7d8bef2..a1f15115eb 100755 --- a/content/ja/docs/tasks/tools/_index.md +++ b/content/ja/docs/tasks/tools/_index.md @@ -1,4 +1,41 @@ --- title: "ツールのインストール" +description: Set up Kubernetes tools on your computer. weight: 10 +no_list: true --- + +## kubectl + +The Kubernetes command-line tool, `kubectl`, allows you to run commands against +Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage +cluster resources, and view logs. + +See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to +download and install `kubectl` and set it up for accessing your cluster. + +You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/). + +## Minikube + +[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run +Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal +computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, +or for daily development work. + +You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/) +guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus +is on getting the tool installed. + +Once you have Minikube working, you can use it to +[run a sample application](/docs/tutorials/hello-minikube/). + +## kind + +Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on +your local compute. Unlike Minikuke, kind only works with a single container runtime: +it requires that you have [Docker](https://docs.docker.com/get-docker/) installed +and configured. + +[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you +need to do to get up and running with kind. From 211acbe51907b2e2645ffd2cd50815af4557a727 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 19 Aug 2020 07:51:54 +0900 Subject: [PATCH 024/303] Translate tasks/tools into Japanese. --- content/ja/docs/tasks/tools/_index.md | 31 ++++++++------------------- 1 file changed, 9 insertions(+), 22 deletions(-) diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md index a1f15115eb..ac97313bb8 100755 --- a/content/ja/docs/tasks/tools/_index.md +++ b/content/ja/docs/tasks/tools/_index.md @@ -1,41 +1,28 @@ --- title: "ツールのインストール" -description: Set up Kubernetes tools on your computer. +description: Kubernetesのツールをローカルのコンピュータ上にセットアップします。 weight: 10 no_list: true --- ## kubectl -The Kubernetes command-line tool, `kubectl`, allows you to run commands against -Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage -cluster resources, and view logs. +Kubernetesのコマンドラインツール`kubectl`を使用すると、Kubernetesクラスターに対してコマンドを実行できるようになります。kubectlは、アプリケーションのデプロイ、クラスターリソースの調査と管理、ログの表示などに使用できます。 -See [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) for information about how to -download and install `kubectl` and set it up for accessing your cluster. +`kubectl`のダウンロードとインストールを行い、クラスターへのアクセスをセットアップする方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参照してください。 -You can also read the [`kubectl` reference documentation](/docs/reference/kubectl/). +また、[`kubectl`リファレンスドキュメント](/ja/docs/reference/kubectl/)も参照できます。 ## Minikube -[Minikube](https://minikube.sigs.k8s.io/) is a tool that lets you run -Kubernetes locally. Minikube runs a single-node Kubernetes cluster on your personal -computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, -or for daily development work. +[Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。 -You can follow the official [Get Started!](https://minikube.sigs.k8s.io/docs/start/) -guide, or read [Install Minikube](/docs/tasks/tools/install-minikube/) if your focus -is on getting the tool installed. +ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従うか、[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を読んでください。 -Once you have Minikube working, you can use it to -[run a sample application](/docs/tutorials/hello-minikube/). +Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。 ## kind -Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on -your local compute. Unlike Minikuke, kind only works with a single container runtime: -it requires that you have [Docker](https://docs.docker.com/get-docker/) installed -and configured. +Minikubeと同じように、[kind](https://kind.sigs.k8s.io/docs/)もローカルコンピューター上でKubernetesを実行するツールです。Minikubeとは違い、kindは1種類のコンテナランタイム上でしか動作しません。実行には[Docker](https://docs.docker.com/get-docker/)のインストールと設定が必要です。 -[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) shows you what you -need to do to get up and running with kind. +[Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/)に、kindの起動に必要な手順が説明されています。 From 2efdc532097d2bece1e2c02fd75e6bce586277d3 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 20 Aug 2020 20:11:28 +0900 Subject: [PATCH 025/303] Update Japanese localization on concepts/containers/runtime-class.md --- .../docs/concepts/containers/runtime-class.md | 60 ++++++------------- 1 file changed, 18 insertions(+), 42 deletions(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index bd6cc59c49..c902cd704c 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -11,20 +11,18 @@ weight: 20 このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。 -{{< warning >}} -RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。 -{{< /warning >}} - - +RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。 -## RuntimeClassについて +## RuntimeClassを使う動機 -RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。 +異なるPodに異なるRuntimeClassを設定することで、パフォーマンスとセキュリティのバランスをとることができます。例えば、ワークロードの一部に高レベルの情報セキュリティ保証が必要な場合、ハードウェア仮想化を使用するコンテナランタイムで実行されるようにそれらのPodをスケジュールすることを選択できます。その後、追加のオーバーヘッドを犠牲にして、代替ランタイムをさらに分離することでメリットが得られます。 -### セットアップ +RuntimeClassを使用して、コンテナランタイムは同じで設定が異なるPodを実行することもできます。 + +## セットアップ RuntimeClass機能のフィーチャーゲートが有効になっていることを確認してください(デフォルトで有効です)。フィーチャーゲートを有効にする方法については、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を参照してください。 その`RuntimeClass`のフィーチャーゲートはApiServerとkubeletのどちらも有効になっていなければなりません。 @@ -32,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ 1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 -#### 1. ノード上でCRI実装を設定する。 +### 1. ノード上でCRI実装を設定する。 RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 @@ -44,7 +42,7 @@ RuntimeClassは、クラスター全体で同じ種類のノード設定であ RuntimeClassの設定は、RuntimeClassによって参照される`ハンドラー`名を持ちます。そのハンドラーは正式なDNS-1123に準拠する形式のラベルでなくてはなりません(英数字 + `-`の文字で構成されます)。 -#### 2. 対応するRuntimeClassリソースを作成する +### 2. 対応するRuntimeClassリソースを作成する ステップ1にて設定する各項目は、関連する`ハンドラー` 名を持ちます。それはどの設定かを指定するものです。各ハンドラーにおいて、対応するRuntimeClassオブジェクトが作成されます。 @@ -68,7 +66,7 @@ RuntimeClassの書き込み操作(create/update/patch/delete)はクラスター Overview](/docs/reference/access-authn-authz/authorization/)を参照してください。 {{< /note >}} -### 使用例 +## 使用例 一度RuntimeClassがクラスターに対して設定されると、それを使用するのは非常に簡単です。PodSpecの`runtimeClassName`を指定してください。 例えば @@ -119,17 +117,15 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -CRI-Oの[設定に関するドキュメント][100]の詳細は下記を参照してください。 +CRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)の詳細は下記を参照してください。 -[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md - -### スケジューリング {#scheduling} +## スケジューリング {#scheduling} {{< feature-state for_k8s_version="v1.16" state="beta" >}} Kubernetes 1.16では、RuntimeClassは`scheduling`フィールドを使ったクラスター内での異なる設定をサポートしています。 このフィールドによって、設定されたRuntimeClassをサポートするノードに対してPodがスケジュールされることを保証できます。 -スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー][]を有効にしなければなりません。(1.16ではデフォルトです) +スケジューリングをサポートするためにはRuntimeClass [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)を有効にしなければなりません。(1.16ではデフォルトです) 特定のRuntimeClassをサポートしているノードへPodが配置されることを保証するために、各ノードは`runtimeclass.scheduling.nodeSelector`フィールドによって選択される共通のラベルを持つべきです。 RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSelectorに統合され、効率よくノードを選択します。 @@ -138,40 +134,20 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele もしサポートされているノードが他のRuntimeClassのPodが稼働しないようにtaint付与されていた場合、RuntimeClassに対して`tolerations`を付与することができます。 `nodeSelector`と同様に、tolerationsはPodのtolerationsにアドミッション機能によって統合され、効率よく許容されたノードを選択します。 -ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/configuration/assign-pod-node/)を参照してください。 - -[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/ +ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/docs/concepts/scheduling-eviction/assign-pod-node/)を参照してください。 ### Podオーバーヘッド -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} -Kubernetes 1.16ではRuntimeClassは[`PodOverhead`](/docs/concepts/configuration/pod-overhead/)機能の一部である、Podが稼働する時に関連するオーバーヘッドを指定することをサポートしています。 -`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです) +Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 +Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです) -PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。 +PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 -### RutimeClassをα版からβ版にアップグレードする -RuntimeClassのβ版の機能は、下記の変更点を含みます。 - -- `node.k8s.io`APIグループと`runtimeclasses.node.k8s.io`リソースはCustomResourceDefinitionからビルトインAPIへとマイグレーションされました。 -- `spec`はRuntimeClassの定義内にインライン化されました(RuntimeClassSpecはすでにありません)。 -- `runtimeHandler`フィールドは`handler`にリネームされました。 -- `handler`フィールドは、全てのAPIバージョンにおいて必須となりました。これはα版のAPIでの`runtimeHandler`フィールドもまた必須であることを意味します。 -- `handler`フィールドは正しいDNSラベルの形式である必要があり([RFC 1123](https://tools.ietf.org/html/rfc1123))、これは`.`文字はもはや含むことができないことを意味します(全てのバージョンにおいて)。有効なハンドラー名は、次の正規表現に従います。`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$` - -**Action Required:** 次のアクションはRuntimeClassのα版からβ版へのアップグレードにおいて対応が必須です。 - -- RuntimeClassリソースはKubernetes v1.14にアップグレードされた*後に* 再作成されなくてはなりません。そして`runtimeclasses.node.k8s.io`というCRDは手動で削除されるべきです。 - ``` - kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io - ``` -- `runtimeHandler`の指定がないか、もしくは空文字の場合や、ハンドラー名に`.`文字列が使われている場合はα版のRuntimeClassにおいてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。 - - -### 参考文献 +## {{% heading "次の項目" %}} - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) From b90563f347647985101af05751a9e44aaaf68994 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 09:45:26 +0900 Subject: [PATCH 026/303] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: makocchi --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c902cd704c..c170e7fced 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -147,7 +147,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。 -## {{% heading "次の項目" %}} +## {{% heading "whatsnext" %}} - [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) From 0a75fa0baef51c4fa75b27e8fa04a2b73fef3385 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 13:02:31 +0900 Subject: [PATCH 027/303] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c170e7fced..c16b522af9 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -30,7 +30,7 @@ RuntimeClass機能のフィーチャーゲートが有効になっているこ 1. ノード上でCRI実装を設定する。(ランタイムに依存) 2. 対応するRuntimeClassリソースを作成する。 -### 1. ノード上でCRI実装を設定する。 +### 1. ノード上でCRI実装を設定する RuntimeClassを通じて利用可能な設定はContainer Runtime Interface (CRI)の実装依存となります。 ユーザーの環境のCRI実装の設定方法は、対応するドキュメント([下記](#cri-configuration))を参照ください。 From 9731c566a8ff6199d24416b7168f6cc7300d2bf1 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 13:02:42 +0900 Subject: [PATCH 028/303] Update content/ja/docs/concepts/containers/runtime-class.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/containers/runtime-class.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index c16b522af9..395a520eb5 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -117,7 +117,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -CRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)の詳細は下記を参照してください。 +詳細はCRI-Oの[設定に関するドキュメント](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)を参照してください。 ## スケジューリング {#scheduling} From cd625d0a520fcec0548d6f3622b4f72c3b758394 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:06:31 +0900 Subject: [PATCH 029/303] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index d76e60f5c3..3fb8a88efd 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -23,7 +23,7 @@ weight: 30 * {{< include "default-storage-class-prereqs.md" >}} * このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/) と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 - さらには[Pod](/ja/docs/concepts/workloads/pods/pod/)、 + さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの 他のコアな概念に精通していることを前提としています。 @@ -264,7 +264,7 @@ Podを強制的にReadyではない状態にする間、上記の`SELECT @@serve ### Readiness Probeを壊す `mysql`コンテナに対する -[readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes) +[readiness probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) は、`mysql -h 127.0.0.1 -e 'SELECT 1'`コマンドを実行することで、サーバーが起動していてクエリーが実行できることを確認します。 このreadiness probeを失敗させる1つの方法は、そのコマンドを壊すことです。 From 1b30cc320b5225f23f5db52d2178810f0c2bd00d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:10:50 +0900 Subject: [PATCH 030/303] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index 3fb8a88efd..4d21a034b7 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -25,7 +25,7 @@ weight: 30 と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 - [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)などの + [ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)などの 他のコアな概念に精通していることを前提としています。 * MySQLに関する知識は記事の理解に役立ちますが、 このチュートリアルは他のシステムにも役立つ一般的なパターンを提示することを目的としています。 From dd216b3ffc4ab15352fa4d54011416e48cc09a71 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 22:13:15 +0900 Subject: [PATCH 031/303] Update run-replicated-stateful-application.md --- .../run-application/run-replicated-stateful-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md index 4d21a034b7..18b4dda5bb 100644 --- a/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/ja/docs/tasks/run-application/run-replicated-stateful-application.md @@ -21,7 +21,7 @@ weight: 30 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -* このチュートリアルは、あなたが[PersistentVolume](/docs/concepts/storage/persistent-volumes/) +* このチュートリアルは、あなたが[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/) と[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)、 さらには[Pod](/ja/docs/concepts/workloads/pods/)、 [Service](/ja/docs/concepts/services-networking/service/)、 From 916881f70f4b8210108d6534bbff7a7b8b3365cc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 12:51:04 +0900 Subject: [PATCH 032/303] update ja communicate-containers-same-pod-shared-volume.md --- .../communicate-containers-same-pod-shared-volume.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index fa5cc9f976..c5a2e88c01 100644 --- a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 +このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。 @@ -100,12 +100,15 @@ nginxコンテナへのシェルを取得します: debianコンテナがnginxルートディレクトリに`index.html`ファイルを作成したことを思い出してください。 `curl`を使用して、GETリクエストをnginxサーバーに送信します: - root@two-containers:/# curl localhost +``` +root@two-containers:/# curl localhost +``` 出力は、nginxがdebianコンテナによって書かれたWebページを提供することを示しています: - Hello from the debian container - +``` +Hello from the debian container +``` From 821aeb70ba4d7b4db8c3c06ea940d807ce941d39 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 12:54:28 +0900 Subject: [PATCH 033/303] update ja communicate-containers-same-pod-shared-volume.md --- .../communicate-containers-same-pod-shared-volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index c5a2e88c01..8a0d37d28e 100644 --- a/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 +このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 コンテナ間で[プロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)ことにより、プロセスが通信できるようにする方法も参照してください。 From 469e3ba973314f9abd50cb5064c9ad0a6441c207 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 17:53:56 +0900 Subject: [PATCH 034/303] Update garbage-collection.md --- .../docs/concepts/workloads/controllers/garbage-collection.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md index 264984bae7..3a1e630d20 100644 --- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -83,9 +83,6 @@ Kubernetes1.7では、認証されていない従属オブジェクトがオー カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。 -Kubernetes1.9以前では多くのコントローラーにおけるデフォルトのガベージコレクションポリシーは`orphan`でした。 -この対象のコントローラーはReplicationController、ReplicaSet、StatefulSet、DaemonSetとDeploymentを含みます。`extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2`のグループバージョンに含まれるオブジェクト種においては、もしユーザーがガベージコレクションに他の値を設定しない限り、デフォルトで従属オブジェクトはみなしご(orphaned)になります。 -Kubernetes1.9において、`apps/v1`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。 下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。 From 2de0c23a1fee634b99a061a44c1d59ecf904a55e Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 14:52:18 +0900 Subject: [PATCH 035/303] Update install-service-catalog-using-helm.md --- .../tasks/service-catalog/install-service-catalog-using-helm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md index bd9bc35465..eced279efc 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -13,7 +13,7 @@ content_type: task ## {{% heading "prerequisites" %}} -* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 * KubernetesクラスターのクラスターDNSを有効化する必要があります。 * クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。 From 8c762dc6a6909b8aaf1171252587ca3bbe4fdc27 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 27 Aug 2020 18:22:51 +0900 Subject: [PATCH 036/303] Update replicaset.md --- .../ja/docs/concepts/workloads/controllers/replicaset.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index f554ffb55c..9f8ccfc377 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -2,7 +2,7 @@ reviewers: title: ReplicaSet content_type: concept -weight: 10 +weight: 20 --- @@ -207,9 +207,9 @@ ReplicaSetオブジェクトの名前は、有効な `.spec.selector`フィールドは[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)です。 [先ほど](#how-a-replicaset-works)議論したように、ReplicaSetが所有するPodを指定するためにそのラベルが使用されます。 先ほどの`frontend.yaml`の例では、そのセレクターは下記のようになっていました -```shell +```yaml matchLabels: - tier: frontend + tier: frontend ``` そのReplicaSetにおいて、`.spec.template.metadata.labels`フィールドの値は`spec.selector`と一致しなくてはならず、一致しない場合はAPIによって拒否されます。 @@ -281,7 +281,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml 同様のことを行うための代替案として、`kubectl autoscale`コマンドも使用できます。(こちらの方がより簡単です。) ```shell -kubectl autoscale rs frontend --max=10 +kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 ``` ## ReplicaSetの代替案 From 26a8a1ce637bd74bceadc75c8b3a9fa24e040a29 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 19:53:55 +0900 Subject: [PATCH 037/303] Update Japanese localization on tasks/inject-data-application/define-environment-variable-container.md --- .../define-environment-variable-container.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md index 3457783864..2427603f35 100644 --- a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -22,11 +22,11 @@ weight: 20 Podを作成するとき、そのPodで実行するコンテナに環境変数を設定することができます。環境変数を設定するには、設定ファイルに `env` または `envFrom` フィールドを含めます。 -この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定ファイルを以下に示します: +この演習では、1つのコンテナを実行するPodを作成します。Podの設定ファイルには、名前 `DEMO_GREETING`、値 `"Hello from the environment"`を持つ環境変数が定義されています。Podの設定マニフェストを以下に示します: {{< codenew file="pods/inject/envars.yaml" >}} -1. YAML設定ファイルに基づいてPodを作成します: +1. マニフェストに基づいてPodを作成します: ```shell kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml @@ -54,7 +54,8 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数 1. シェルで`printenv`コマンドを実行すると、環境変数の一覧が表示されます。 ```shell - root@envar-demo:/# printenv + # コンテナ内のシェルで以下のコマンドを実行します + printenv ``` 出力は以下のようになります: @@ -74,6 +75,10 @@ Podを作成するとき、そのPodで実行するコンテナに環境変数 `env`または`envFrom`フィールドを使用して設定された環境変数は、コンテナイメージで指定された環境変数を上書きします。 {{< /note >}} +{{< note >}} +環境変数は相互に参照でき、循環して使用可能です。使用する前に順序に注意してください。 +{{< /note >}} + ## 設定の中で環境変数を使用する {#using-environment-variables-inside-of-your-config} Podの設定で定義した環境変数は、Podのコンテナに設定したコマンドや引数など、設定の他の場所で使用することができます。以下の設定例では、環境変数`GREETING`、`HONORORIFIC`、`NAME`にそれぞれ `Warm greetings to`、`The Most Honorable`、`Kubernetes`を設定しています。これらの環境変数は、`env-print-demo`コンテナに渡されるCLI引数で使われます。 From ac62dadf5b123e9df89f35b6bd1c492f05ee0687 Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Tue, 25 Aug 2020 18:49:54 +0900 Subject: [PATCH 038/303] Update content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md to follow v1.18 of the original (English) text --- .../configure-liveness-readiness-startup-probes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index bd5ec92082..68929ec5bb 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -8,7 +8,7 @@ weight: 110 このページでは、Liveness Probe、Readiness ProbeおよびStartup Probeの使用方法について説明します。 -[kubelet](/docs/admin/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 +[kubelet](/docs/reference/command-line-tools-reference/kubelet/)は、Liveness Probeを使用して、コンテナをいつ再起動するかを認識します。 例えば、アプリケーション自体は起動しているが、処理を継続することができないデッドロック状態を検知することができます。 このような状態のコンテナを再起動することで、バグがある場合でもアプリケーションの可用性を高めることができます。 @@ -296,7 +296,7 @@ Liveness ProbeおよびReadiness Probeのチェック動作をより正確に制 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 -* `failureThreshold`: Podが開始してProbeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 +* `failureThreshold`: Probeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。 From 1b0b3099018a4c4216ac1a89458ec02036eda3c7 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 21:27:52 +0900 Subject: [PATCH 039/303] Update run-stateless-application-deployment.md --- .../run-application/run-stateless-application-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md index 88a35b7d84..963df78524 100644 --- a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md @@ -96,7 +96,7 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー ## Deploymentの更新 -新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.8を使用するように指定しています。 +新しいYAMLファイルを適用してDeploymentを更新できます。このYAMLファイルは、Deploymentを更新してnginx 1.16.1を使用するように指定しています。 {{< codenew file="application/deployment-update.yaml" >}} From 5fc11ca307d69e8d62ecb016ecc92276f2476bc2 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 26 Aug 2020 20:01:25 +0900 Subject: [PATCH 040/303] Update install-service-catalog-using-sc.md --- .../tasks/service-catalog/install-service-catalog-using-sc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md index a0211e2a18..86b4e589e6 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -12,7 +12,7 @@ GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-ser ## {{% heading "prerequisites" %}} -* [サービスカタログ](/docs/concepts/service-catalog/)の基本概念を理解してください。 +* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。 * [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。 * SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。 * サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。 From fcee7bcc7f7115a842f93c1fd37d246e93b3149a Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 20:42:11 +0900 Subject: [PATCH 041/303] Update Japanese localization on tasks/run-application/_index.md --- content/ja/docs/tasks/run-application/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/run-application/_index.md b/content/ja/docs/tasks/run-application/_index.md index c00f88f4bb..17d2339e7e 100755 --- a/content/ja/docs/tasks/run-application/_index.md +++ b/content/ja/docs/tasks/run-application/_index.md @@ -1,5 +1,6 @@ --- title: "アプリケーションの実行" +description: ステートレスアプリケーションとステートフルアプリケーションの両方を実行および管理します。 weight: 40 --- From a0e8cf7913d05169174f69041ce7b0174c6b070d Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 19:22:13 +0900 Subject: [PATCH 042/303] Update Japanese localization on tasks/inject-data-application/_index.md --- content/ja/docs/tasks/inject-data-application/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/inject-data-application/_index.md b/content/ja/docs/tasks/inject-data-application/_index.md index 52c5ca5128..a28c380a26 100644 --- a/content/ja/docs/tasks/inject-data-application/_index.md +++ b/content/ja/docs/tasks/inject-data-application/_index.md @@ -1,4 +1,5 @@ --- title: "アプリケーションへのデータ注入" +description: ワークロードを実行するPodの構成とその他のデータを指定します。 weight: 30 --- From 4343035a9195d020d54fd184b726e64196f86964 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 28 Aug 2020 22:06:05 +0900 Subject: [PATCH 043/303] Update quality-service-pod.md --- .../configure-pod-container/quality-service-pod.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md index 010af1dc64..012921d2bf 100644 --- a/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ja/docs/tasks/configure-pod-container/quality-service-pod.md @@ -241,17 +241,17 @@ kubectl delete namespace qos-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From 045cf0cc246a99c43fc560f254c82d9e9a95ae6e Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 12:10:16 +0900 Subject: [PATCH 044/303] update controller.md --- content/ja/docs/concepts/architecture/controller.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index 0a13635fe8..9a01c2d485 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -62,12 +62,10 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす ## 設計 -設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 -たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 - {{< note >}} 同じ種類のオブジェクトを作成または更新するコントローラーが、複数存在する場合があります。実際には、Kubernetesコントローラーは、自分が制御するリソースに関連するリソースにのみ注意を払うように作られています。 @@ -88,3 +86,4 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 + From ab82c697f491c070ac585a6af276598567aa63a8 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 17:10:24 +0900 Subject: [PATCH 045/303] delete unnecessary space --- content/ja/docs/concepts/architecture/controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index 9a01c2d485..c2f71c9029 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -62,7 +62,7 @@ Kubernetesはシステムに対してクラウドネイティブな見方をす ## 設計 -設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。 たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 +設計理念として、Kubernetesは多数のコントローラーを使用しており、各コントローラーはクラスターの状態の特定の側面をそれぞれ管理しています。最もよくあるパターンは、特定の制御ループ(コントローラー)が目的の状態として1種類のリソースを使用し、目的の状態を実現することを管理するために別の種類のリソースを用意するというものです。たとえば、Jobのコントローラーは、Jobオブジェクト(新しい処理を見つけるため)およびPodオブジェクト(Jobを実行し、処理が完了したか確認するため)を監視します。この場合、なにか別のものがJobを作成し、JobコントローラーはPodを作成します。 相互にリンクされた単一のモノリシックな制御ループよりは、複数の単純なコントローラーが存在する方が役に立ちます。コントローラーは故障することがあるため、Kubernetesは故障を許容するように設計されています。 From 7f5c052bf829cf7f0223eca94ca4416a4dc7b5fd Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 25 Aug 2020 00:03:02 +0900 Subject: [PATCH 046/303] Update debug-stateful-set.md --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index 2f42f38cc2..d0fffb6b95 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/manage-stateful-set/delete-pods/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 From acea56b17ae2e283ea54a9d3be4b58274f72a29b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 19:37:59 +0900 Subject: [PATCH 047/303] Update content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md Co-authored-by: inductor(Kohei) --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index d0fffb6b95..0cafaa28e5 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podsの削除](/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 @@ -39,4 +39,3 @@ Podが長期間`Unknown`または`Terminating`の状態になっていること - From ae2fedaf19041f4db5d5607cc7176b9834ef8362 Mon Sep 17 00:00:00 2001 From: hideUW Date: Sun, 23 Aug 2020 21:42:39 -0700 Subject: [PATCH 048/303] Update the document to follow v1.18. --- .../get-shell-running-container.md | 63 +++++++++++-------- 1 file changed, 36 insertions(+), 27 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 684fa981c1..60ac92f614 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -43,7 +43,7 @@ kubectl get pod shell-demo 実行中のコンテナへのシェルを取得します: ```shell -kubectl exec -it shell-demo -- /bin/bash +kubectl exec --stdin --tty shell-demo -- /bin/bash ``` {{< note >}} @@ -54,23 +54,25 @@ kubectl exec -it shell-demo -- /bin/bash シェル内で、ルートディレクトリーのファイル一覧を表示します: ```shell -root@shell-demo:/# ls / +# このコマンドをコンテナ内で実行します +ls / ``` シェル内で、他のコマンドを試しましょう。以下がいくつかの例です: ```shell -root@shell-demo:/# ls / -root@shell-demo:/# cat /proc/mounts -root@shell-demo:/# cat /proc/1/maps -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install -y tcpdump -root@shell-demo:/# tcpdump -root@shell-demo:/# apt-get install -y lsof -root@shell-demo:/# lsof -root@shell-demo:/# apt-get install -y procps -root@shell-demo:/# ps aux -root@shell-demo:/# ps aux | grep nginx +# これらのサンプルコマンドをコンテナ内で実行することができます +ls / +cat /proc/mounts +cat /proc/1/maps +apt-get update +apt-get install -y tcpdump +tcpdump +apt-get install -y lsof +lsof +apt-get install -y procps +ps aux +ps aux | grep nginx ``` ## nginxのルートページへの書き込み @@ -81,25 +83,31 @@ Podの設定ファイルを再度確認します。Podは`emptyDir`ボリュー シェル内で、`/usr/share/nginx/html`ディレクトリに`index.html`を作成します。 ```shell -root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +# このコマンドをコンテナ内で実行します +echo 'Hello shell demo' > /usr/share/nginx/html/index.html ``` シェル内で、nginxサーバーにGETリクエストを送信します: ```shell -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install curl -root@shell-demo:/# curl localhost +# これらのコマンドをコンテナ内のシェルで実行します +apt-get update +apt-get install curl +curl http://localhost/ ``` 出力に`index.html`ファイルに書き込んだ文字列が表示されます: -```shell +``` Hello shell demo ``` シェルを終了する場合、`exit`を入力します。 +```shell +exit # コンテナ内のシェルを終了する +``` + ## コンテナ内での各コマンドの実行 シェルではない通常のコマンドウインドウ内で、実行中のコンテナの環境変数の一覧を表示します: @@ -111,9 +119,9 @@ kubectl exec shell-demo env 他のコマンドを試します。以下がいくつかの例です: ```shell -kubectl exec shell-demo ps aux -kubectl exec shell-demo ls / -kubectl exec shell-demo cat /proc/1/mounts +kubectl exec shell-demo -- ps aux +kubectl exec shell-demo -- ls / +kubectl exec shell-demo -- cat /proc/1/mounts ``` @@ -123,20 +131,21 @@ kubectl exec shell-demo cat /proc/1/mounts ## Podが1つ以上のコンテナを持つ場合にシェルを開く Podが1つ以上のコンテナを持つ場合、`--container`か`-c`を使用して、`kubectl exec`コマンド内でコンテナを指定します。 -例えば、my-podという名前のPodがあり、そのPodがmain-appとhelper-appという2つのコンテナを持つとします。 -以下のコマンドはmain-appのコンテナへのシェルを開きます。 +例えば、my-podという名前のPodがあり、そのPodが _main-app_ と _helper-app_ という2つのコンテナを持つとします。 +以下のコマンドは _main-app_ のコンテナへのシェルを開きます。 ```shell -kubectl exec -it my-pod --container main-app -- /bin/bash +kubectl exec -i -t my-pod --container main-app -- /bin/bash ``` - - +{{< note >}} +ショートオプションの `-i` と `-t` は、ロングオプションの `--stdin` と `--tty` と同様です。 +{{< /note >}} ## {{% heading "whatsnext" %}} -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む。 From cc4ba71849a1fbe87e405191ded781ad6b4f0896 Mon Sep 17 00:00:00 2001 From: hide Date: Sun, 23 Aug 2020 21:55:01 -0700 Subject: [PATCH 049/303] Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Co-authored-by: Naoki Oketani --- .../debug-application-cluster/get-shell-running-container.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 60ac92f614..585916da42 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -139,7 +139,7 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash ``` {{< note >}} -ショートオプションの `-i` と `-t` は、ロングオプションの `--stdin` と `--tty` と同様です。 +ショートオプションの`-i`と`-t`は、ロングオプションの`--stdin`と`--tty`と同様です。 {{< /note >}} ## {{% heading "whatsnext" %}} @@ -150,4 +150,3 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash - From d083d397506fccdde3454cdb8fd6fdd979ceb810 Mon Sep 17 00:00:00 2001 From: hide Date: Sun, 30 Aug 2020 13:44:19 -0700 Subject: [PATCH 050/303] Update content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md Co-authored-by: inductor(Kohei) --- .../debug-application-cluster/get-shell-running-container.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md index 585916da42..bada044869 100644 --- a/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/ja/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -145,8 +145,7 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash ## {{% heading "whatsnext" %}} -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む。 - +* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)について読む From a144437c21b110b28ffca3e181034d592943a0ad Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 26 Aug 2020 12:23:17 +0900 Subject: [PATCH 051/303] update ja/doc networking --- .../cluster-administration/networking.md | 33 +++++++++++-------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 53b899dc32..fa0fe884ff 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -9,7 +9,7 @@ weight: 50 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。 Kubernetesには、4つの異なる対応すべきネットワークの問題があります: -1. 高度に結合されたコンテナ間の通信: これは、[Pod](/ja/docs/concepts/workloads/pods/pod/)および`localhost`通信によって解決されます。 +1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pods" term_id="pod" >}}および`localhost`通信によって解決されます。 2. Pod間の通信: 本ドキュメントの主な焦点です。 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 @@ -67,7 +67,7 @@ Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to i ### AOS from Apstra -[AOS](http://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. +[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. @@ -75,7 +75,7 @@ AOS has a rich set of REST API endpoints that enable Kubernetes to quickly chang AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. -Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/ +Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ ### AWS VPC CNI for Kubernetes @@ -97,7 +97,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)] (https:/ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). ### Cilium @@ -109,7 +109,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#kubernetesのネットワークモデル) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. @@ -131,11 +131,11 @@ network complexity required to deploy Kubernetes at scale within AWS. ### Contiv -[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced. +[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. ### Contrail / Tungsten Fabric -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. +[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads. ### DANM @@ -216,7 +216,7 @@ traffic to the internet. ### Kube-router -[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. +[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer. ### L2 networks and linux bridging @@ -226,8 +226,8 @@ Note that these instructions have only been tried very casually - it seems to work, but has not been thoroughly tested. If you use this technique and perfect the process, please let us know. -Follow the "With Linux Bridge devices" section of [this very nice -tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from +Follow the "With Linux Bridge devices" section of +[this very nice tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from Lars Kellogg-Stedman. ### Multus (a Multi Network plugin) @@ -236,6 +236,10 @@ Lars Kellogg-Stedman. Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes. +### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin) + +[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking + ### NSX-T [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal. @@ -244,7 +248,7 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p ### Nuage Networks VCS (Virtualized Cloud Services) -[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. +[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. @@ -264,7 +268,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). ### Project Calico -[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine. +[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. @@ -272,7 +276,7 @@ Calico can also be run in policy enforcement mode in conjunction with other netw ### Romana -[Romana](http://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. +[Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. ### Weave Net from Weaveworks @@ -287,5 +291,6 @@ to run, and in both cases, the network provides one IP address per pod - as is s ## {{% heading "whatsnext" %}} -ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 +ネットワークモデルの初期設計とその根拠、および将来の計画については、 +[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 From b73acdfa6ac613d51b1ef8d3757bba1276a0a2bd Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 27 Aug 2020 17:17:25 +0900 Subject: [PATCH 052/303] fix newline --- content/ja/docs/concepts/cluster-administration/networking.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index fa0fe884ff..1ceaae40aa 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -291,6 +291,5 @@ to run, and in both cases, the network provides one IP address per pod - as is s ## {{% heading "whatsnext" %}} -ネットワークモデルの初期設計とその根拠、および将来の計画については、 -[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 +ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 From cb7ad7d3adec85610fec646b1d571d0832a7c4da Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:14:23 +0900 Subject: [PATCH 053/303] update word and link --- .../ja/docs/concepts/cluster-administration/networking.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index 1ceaae40aa..05af3690d1 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -9,7 +9,7 @@ weight: 50 ネットワークはKubernetesにおける中心的な部分ですが、どのように動作するかを正確に理解することは難解な場合もあります。 Kubernetesには、4つの異なる対応すべきネットワークの問題があります: -1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pods" term_id="pod" >}}および`localhost`通信によって解決されます。 +1. 高度に結合されたコンテナ間の通信: これは、{{< glossary_tooltip text="Pod" term_id="pod" >}}および`localhost`通信によって解決されます。 2. Pod間の通信: 本ドキュメントの主な焦点です。 3. Podからサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 4. 外部からサービスへの通信：これは[Service](/ja/docs/concepts/services-networking/service/)でカバーされています。 @@ -24,7 +24,7 @@ Kubernetesは、言ってしまえばアプリケーション間でマシンを 動的ポート割り当てはシステムに多くの複雑さをもたらします。すべてのアプリケーションはパラメータとしてポートを管理する必要があり、APIサーバーにて動的なポート番号を設定値として注入する方法が必要となり、各サービスはお互いにお互いを見つける方法が必要です。Kubernetesはこれに対処するのではなく、別のアプローチを取ります。 -## Kubernetesのネットワークモデル +## Kubernetesのネットワークモデル {#the-kubernetes-network-model} すべての`Pod`は独自のIPアドレスを持ちます。これは、`Pod`間のリンクを明示的に作成する必要がなく、コンテナポートをホストポートにマッピングする必要がほとんどないことを意味します。こうすることで、ポート割り当て、名前解決、サービスディスカバリー、負荷分散、アプリケーション設定、および移行の観点から、`Pod`をVMまたは物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。 @@ -109,7 +109,7 @@ addressing, and it can be used in combination with other CNI plugins. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#kubernetesのネットワークモデル) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin. From aa0cbfe61fc03fbc79a31d362d94f62b8cb8fd5c Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 01:07:16 +0900 Subject: [PATCH 054/303] Update debug-pod-replication-controller.md --- .../debug-pod-replication-controller.md | 37 ++----------------- 1 file changed, 4 insertions(+), 33 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index fc17886ebe..e47fdd5470 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -47,9 +47,9 @@ Podをスケジュールできない理由に関するスケジューラーか クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。 この場合、いくつかのことを試すことができます。 -* クラスターに[ノードを追加します](/docs/admin/cluster-management/#resizing-a-cluster)。 +* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 -* [不要なPodを終了](/docs/user-guide/pods/single-container/#deleting_a_pod)して、 +* [不要なPodを終了](docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 * Podがノードよりも大きくないことを確認します。 @@ -86,37 +86,8 @@ Podが`Waiting`状態となる最も一般的な原因は、イメージをプ ### Podがクラッシュする、あるいはUnhealthy状態 -最初に、現在のコンテナのログを確認して下さい。 - -```shell -kubectl logs ${POD_NAME} ${CONTAINER_NAME} -``` - -以前にコンテナがクラッシュした場合、次のコマンドで以前のコンテナのクラッシュログにアクセスできます。 - -```shell -kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} -``` - -別の方法として、`exec`を使用してそのコンテナ内でコマンドを実行できます。 - -```shell -kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} -``` - -{{< note >}} -`-c ${CONTAINER_NAME}`はオプションです。単一のコンテナのみを含むPodの場合は省略できます。 -{{< /note >}} - -例えば、実行中のCassandra Podのログを確認するには、次のコマンドを実行します。 - -```shell -kubectl exec cassandra -- cat /var/log/cassandra/system.log -``` - -クラスターで有効にしていれば、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) を既存のPodに追加することもできます。 新しい一時的なコンテナを利用して、たとえばPod内の問題の診断のために任意のコマンドを実行することができます。利用できる機能を含む詳細については、 [エフェメラルコンテナ](/docs/concepts/workloads/pods/ephemeral-containers/) のページを参照してください。 - -これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。 +Podがスケジュールされると、[Debug Running Pods]( ++/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 ## ReplicationControllerのデバッグ From a74f06a0fe691641dcc17a923c9282e4470e0eb5 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 01:16:03 +0900 Subject: [PATCH 055/303] Update debug-pod-replication-controller.md --- .../debug-pod-replication-controller.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index e47fdd5470..570134b84d 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -49,7 +49,7 @@ Podをスケジュールできない理由に関するスケジューラーか * クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 -* [不要なPodを終了](docs/concepts/workloads/pods/#pod-termination)して、 +* [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 * Podがノードよりも大きくないことを確認します。 @@ -86,8 +86,7 @@ Podが`Waiting`状態となる最も一般的な原因は、イメージをプ ### Podがクラッシュする、あるいはUnhealthy状態 -Podがスケジュールされると、[Debug Running Pods]( -+/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 +Podがスケジュールされると、[動作中のPodをデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。 ## ReplicationControllerのデバッグ From 87c0bcadcdb69e500253007e05c9a3512d095e4e Mon Sep 17 00:00:00 2001 From: opeco17 Date: Tue, 25 Aug 2020 00:43:25 +0900 Subject: [PATCH 056/303] fix 24484 --- .../debug-service.md | 65 +++++++++++-------- 1 file changed, 37 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index a8332cbcfb..3cdf42ca87 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -34,9 +34,9 @@ kubectl exec -c -- このドキュメントのウォークスルーのために、いくつかのPodを実行しましょう。おそらくあなた自身のServiceをデバッグしているため、あなた自身の詳細に置き換えることもできますし、これに沿って2番目のデータポイントを取得することもできます。 + ```shell -kubectl run hostnames --image=k8s.gcr.io/serve_hostname \ - --replicas=3 +kubectl create deployment hostnames --image=k8s.gcr.io/serve_hostname ``` ```none deployment.apps/hostnames created @@ -45,6 +45,15 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 +Deplymentを3つのreplicaにスケールさせてみましょう。 + +```shell +kubectl scale deployment hostnames --replicas=3 +``` +```none +deployment.apps/hostnames scaled +``` + これは、次のYAMLでDeploymentを開始した場合と同じです。 ```yaml @@ -52,27 +61,29 @@ apiVersion: apps/v1 kind: Deployment metadata: name: hostnames + labels: + app: hostnames spec: selector: matchLabels: - run: hostnames + app: hostnames replicas: 3 template: metadata: labels: - run: hostnames + app: hostnames spec: containers: - name: hostnames image: k8s.gcr.io/serve_hostname ``` -"run"ラベルは`kubectl run`によって、Deploymentの名前に自動的にセットされます。 +"app"ラベルは`kubectl create deployment`によって、Deploymentの名前に自動的にセットされます。 Podが実行されていることを確認できます。 ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE @@ -84,7 +95,7 @@ hostnames-632524106-tlaok 1/1 Running 0 2m Podが機能していることも確認できます。Pod IP アドレスリストを取得し、直接テストできます。 ```shell -kubectl get pods -l run=hostnames \ +kubectl get pods -l app=hostnames \ -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}' ``` ```none @@ -106,9 +117,9 @@ done 次のように表示されます。 ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` この時点で期待通りの応答が得られない場合、Podが正常でないか、想定しているポートでリッスンしていない可能性があります。なにが起きているかを確認するために`kubectl logs`が役立ちます。Podに直接に入りデバッグする場合は`kubectl exec`が必要になります。 @@ -312,7 +323,7 @@ kubectl get service hostnames -o json "resourceVersion": "347189", "creationTimestamp": "2015-07-07T15:24:29Z", "labels": { - "run": "hostnames" + "app": "hostnames" } }, "spec": { @@ -326,7 +337,7 @@ kubectl get service hostnames -o json } ], "selector": { - "run": "hostnames" + "app": "hostnames" }, "clusterIP": "10.0.1.175", "type": "ClusterIP", @@ -351,15 +362,15 @@ kubectl get service hostnames -o json 以前に、Podが実行されていることを確認しました。再確認しましょう。 ```shell -kubectl get pods -l run=hostnames +kubectl get pods -l app=hostnames ``` ```none NAME READY STATUS RESTARTS AGE -hostnames-0uton 1/1 Running 0 1h -hostnames-bvc05 1/1 Running 0 1h -hostnames-yp2kp 1/1 Running 0 1h +hostnames-632524106-bbpiw 1/1 Running 0 1h +hostnames-632524106-ly40y 1/1 Running 0 1h +hostnames-632524106-tlaok 1/1 Running 0 1h ``` -`-l run=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。 +`-l app=hostnames`引数はラベルセレクターで、ちょうど私たちの`Service`に定義されているものと同じです。 "AGE"列は、これらのPodが約1時間前のものであることを示しており、それらが正常に実行され、クラッシュしていないことを意味します。 @@ -374,7 +385,7 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスまたは他のエラー、たとえばServiceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 +これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのに、Deploymentが`run=hostnames`を指定しているなど、タイプミスやその他のエラーがあることや、`kubectl run`によってDeploymentを作成することです。 ## Podは機能しているか？ @@ -395,9 +406,9 @@ done 次のように表示されます。 ``` -hostnames-0uton -hostnames-bvc05 -hostnames-yp2kp +hostnames-632524106-bbpiw +hostnames-632524106-ly40y +hostnames-632524106-tlaok ``` Endpointsリスト内の各Podは、それぞれの自身のホスト名を返すはずです。そうならない(または、あなた自身のPodの正しい振る舞いにならない)場合は、そこで何が起こっているのかを調査する必要があります。 @@ -510,7 +521,7 @@ iptables-save | grep hostnames curl 10.0.1.175:80 ``` ```none -hostnames-0uton +hostnames-632524106-bbpiw ``` もしこれが失敗し、あなたがuserspaceプロキシーを使用している場合、プロキシーへの直接アクセスを試してみてください。もしiptablesプロキシーを使用している場合、このセクションはスキップしてください。 @@ -521,7 +532,7 @@ hostnames-0uton curl localhost:48577 ``` ```none -hostnames-yp2kp +hostnames-632524106-tlaok ``` もしまだ失敗する場合は、`kube-proxy`ログで次のような特定の行を探してください。 @@ -534,7 +545,7 @@ Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9 ### エッジケース: PodがService IP経由で自身に到達できない {#a-pod-fails-to-reach-itself-via-the-service-ip} -これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/admin/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 +これはありそうに聞こえないかもしれませんが、実際には起こり、動作するはずです。これはネットワークが"hairpin"トラフィック用に適切に設定されていない場合、通常は`kube-proxy`が`iptables`モードで実行され、Podがブリッジネットワークに接続されている場合に発生します。`Kubelet`は`hairpin-mode`[フラグ](/docs/reference/command-line-tools-reference/kubelet/)を公開します。これにより、Serviceのエンドポイントが自身のServiceのVIPにアクセスしようとした場合に、自身への負荷分散を可能にします。`hairpin-mode`フラグは`hairpin-veth`または`promiscuous-bridge`に設定する必要があります。 この問題をトラブルシューティングする一般的な手順は次のとおりです。 @@ -580,13 +591,11 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 ここまでたどり着いたということは、とてもおかしなことが起こっています。Serviceは実行中で、Endpointsがあり、Podは実際にサービスを提供しています。DNSは動作していて、`kube-proxy`も誤動作していないようです。それでも、あなたのServiceは機能していません。おそらく私たちにお知らせ頂いた方がよいでしょう。調査をお手伝いします！ -[Slack](/docs/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 +[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack)、[Forum](https://discuss.kubernetes.io)または[GitHub](https://github.com/kubernetes/kubernetes)でお問い合わせください。 ## {{% heading "whatsnext" %}} -詳細については、[トラブルシューティングドキュメント](/docs/troubleshooting/)をご覧ください。 - - +詳細については、[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)をご覧ください。 From 212076bc4573035fd6bcb60edbcc31ee779450d3 Mon Sep 17 00:00:00 2001 From: opeco17 <46510874+opeco17@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:28:46 +0900 Subject: [PATCH 057/303] Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-authored-by: Naoki Oketani --- .../ja/docs/tasks/debug-application-cluster/debug-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index 3cdf42ca87..e5a00ebcde 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -45,7 +45,7 @@ deployment.apps/hostnames created `kubectl`コマンドは作成、変更されたリソースのタイプと名前を出力するため、この後のコマンドで使用することもできます。 -Deplymentを3つのreplicaにスケールさせてみましょう。 +Deploymentを3つのレプリカにスケールさせてみましょう。 ```shell kubectl scale deployment hostnames --replicas=3 From b487ca44a39ce76872495476881ff1a40993b8ff Mon Sep 17 00:00:00 2001 From: opeco17 <46510874+opeco17@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:30:43 +0900 Subject: [PATCH 058/303] Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-authored-by: Naoki Oketani --- .../ja/docs/tasks/debug-application-cluster/debug-service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-service.md b/content/ja/docs/tasks/debug-application-cluster/debug-service.md index e5a00ebcde..5daefb2f59 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-service.md @@ -385,7 +385,7 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのに、Deploymentが`run=hostnames`を指定しているなど、タイプミスやその他のエラーがあることや、`kubectl run`によってDeploymentを作成することです。 +これにより、EndpointsコントローラーがServiceの正しいPodを見つけていることを確認できます。`ENDPOINTS`列が``の場合、Serviceの`spec.selector`フィールドが実際にPodの`metadata.labels`値を選択していることを確認する必要があります。よくある間違いは、タイプミスやその他のエラー、たとえばDeployment作成にも`kubectl run`が使われた1.18以前のバージョンのように、Serviceが`app=hostnames`を選択しているのにDeploymentが`run=hostnames`を指定していることです。 ## Podは機能しているか？ From d3db4e1e86e427e822a3685b6e81fc261e87bfc1 Mon Sep 17 00:00:00 2001 From: arisgi Date: Thu, 27 Aug 2020 00:56:37 +0900 Subject: [PATCH 059/303] Translate "Determine the Reason for Pod Failure" --- .../debug-application-cluster/determine-reason-pod-failure.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 7ec722caa6..fdddb859ce 100644 --- a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -67,6 +67,8 @@ content_type: task Kubernetesは、コンテナの`terminationMessagePath`フィールドで指定されている終了メッセージファイルから終了メッセージを取得します。デフォルト値は`/dev/termination-log`です。このフィールドをカスタマイズすることで、Kubernetesに別のファイルを使うように指示できます。Kubernetesは指定されたファイルの内容を使用して、成功と失敗の両方についてコンテナのステータスメッセージを入力します。 +終了メッセージはアサーションエラーメッセージのように、最終状態を簡潔に示します。kubeletは4096バイトより長いメッセージは切り詰めます。全コンテナの合計メッセージの長さの上限は12キビバイトです。デフォルトの終了メッセージのパスは`/dev/termination-log`です。Pod起動後に終了メッセージのパスを設定することはできません。 + 次の例では、コンテナはKubernetesが取得するために終了メッセージを`/tmp/my-log`に書き込みます: ```yaml From 3bc4bafda7628dd1c6216b92a298bbac976f6d75 Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 14:06:04 +0900 Subject: [PATCH 060/303] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 3486c55219..fab17dddc1 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。 -また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。 +また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。 @@ -200,11 +200,11 @@ NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m ``` -このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#what-s-next)にさらに詳細な使用例に関するリンクがあります。 +このシンプルな例を独自のInitコンテナを作成する際の参考にしてください。[次の項目](#whats-next)にさらに詳細な使用例に関するリンクがあります。 ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時において、各Initコンテナはネットワークとボリュームが初期化されたのちに順番に起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時、各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From e6691df38092d884116ecf4d5b353fe1e4a80319 Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 14:10:03 +0900 Subject: [PATCH 061/303] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index fab17dddc1..7ab97eac5d 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -204,7 +204,7 @@ myapp-pod 1/1 Running 0 9m ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時、各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From 731b0da4f71221feed834d92207f0ae35069694d Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 23:34:39 +0900 Subject: [PATCH 062/303] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 7ab97eac5d..2a13f84022 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。 -また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 +また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`lifecycle`、`livenessProbe`、`readinessProbe`および`startupProbe`をサポートしていません。 複数のInitコンテナを単一のPodに対して指定した場合、KubeletはそれらのInitコンテナを1つずつ順番に実行します。各Initコンテナは、次のInitコンテナが稼働する前に正常終了しなくてはなりません。全てのInitコンテナの実行が完了すると、KubeletはPodのアプリケーションコンテナを初期化し、通常通り実行します。 From 60c7c21151073124dedc77e7cb63a81acdc3847c Mon Sep 17 00:00:00 2001 From: Takuya Niita Date: Sat, 29 Aug 2020 23:53:34 +0900 Subject: [PATCH 063/303] modify #23451 --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 2a13f84022..5e7baf0665 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -204,7 +204,7 @@ myapp-pod 1/1 Running 0 9m ## Initコンテナのふるまいに関する詳細 {#detailed-behavior} -Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従って各Initコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 +Podの起動時は各Initコンテナが起動状態となるまで、kubeletはネットワーキングおよびストレージを利用可能な状態にしません。また、kubeletはPodのspecに定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。 From 495415c3f3a1b1fc2a639fbfa4738c623d6f8d1a Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 31 Aug 2020 17:52:13 +0900 Subject: [PATCH 064/303] Update configure-pod-configmap.md --- .../configure-pod-container/configure-pod-configmap.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md index 4666e6c7f2..7bcacd13a4 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -577,6 +577,10 @@ SPECIAL_TYPE `/etc/config/`ディレクトリに何かファイルがある場合、それらは削除されます。 {{< /caution >}} +{{< note >}} +テキストデータはUTF-8文字エンコーディングを使用しているファイルとして公開されます。他の文字エンコーディングを使用する場合は、バイナリデータを使用してください。 +{{< /note >}} + ### ConfigMapデータをボリュームの特定のパスに追加する `path`フィールドを利用して特定のConfigMapのアイテム向けに希望のファイルパスを指定します。 @@ -665,5 +669,5 @@ data: ## {{% heading "whatsnext" %}} -* 実践例[Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。 +* 実践例[ConfigMapを使ったRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)を続けて読む。 From 3d0034f42ccbbf3fd641a1d70ab2c50d2cdbacdf Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 2 Sep 2020 02:52:26 +0900 Subject: [PATCH 065/303] Update attach-handler-lifecycle-event.md --- .../configure-pod-container/attach-handler-lifecycle-event.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 1c875edc1f..1aa194a745 100644 --- a/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -63,7 +63,7 @@ Pod内で実行されているコンテナでシェルを実行します: ただし、コンテナのエントリーポイントが呼び出される前にpostStartハンドラーが呼び出されるという保証はありません。postStartハンドラーはコンテナのコードに対して非同期的に実行されますが、postStartハンドラーが完了するまでコンテナのKubernetesによる管理はブロックされます。postStartハンドラーが完了するまで、コンテナのステータスはRUNNINGに設定されません。 Kubernetesはコンテナが終了する直前にpreStopイベントを送信します。 -コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podの終了](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)を参照してください。 +コンテナのKubernetesによる管理は、Podの猶予期間が終了しない限り、preStopハンドラーが完了するまでブロックされます。詳細は[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。 {{< note >}} Kubernetesは、Podが *終了* したときにのみpreStopイベントを送信します。 From b82b1ff73c20c97f69e8f800ef24a1d94dbb59ad Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:48:43 +0900 Subject: [PATCH 066/303] update ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md --- .../connecting-frontend-backend.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index dbe76f3267..b58ba00914 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -26,10 +26,10 @@ weight: 70 ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。 - ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。 +このタスクでは[Serviceで外部ロードバランサー](/docs/tasks/access-application-cluster/create-external-load-balancer/)を使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。 +ご使用の環境がこれをサポートしていない場合は、代わりにタイプ[NodePort](/ja/docs/concepts/services-networking/service/#nodeport)のServiceを使用できます。 @@ -186,8 +186,19 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま {"message":"Hello"} ``` +## {{% heading "cleanup" %}} +Serviceを削除するために、このコマンドを入力してください： +```shell +kubectl delete services frontend hello +``` + +バックエンドとして動作しているDeploymentとReplicaSetとPodとフロントエンドアプリケーションを削除するために、このコマンドを入力してください： + +```shell +kubectl delete deployment frontend hello +``` ## {{% heading "whatsnext" %}} From 61d24d77875406e9d913d3e05140464ba480c08a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 31 Aug 2020 12:55:23 +0900 Subject: [PATCH 067/303] update ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md --- .../access-application-cluster/connecting-frontend-backend.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index b58ba00914..e8af3d5f7a 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -194,7 +194,7 @@ Serviceを削除するために、このコマンドを入力してください kubectl delete services frontend hello ``` -バックエンドとして動作しているDeploymentとReplicaSetとPodとフロントエンドアプリケーションを削除するために、このコマンドを入力してください： +バックエンドとフロントエンドアプリケーションを実行しているDeploymentとReplicaSetとPodを削除するために、このコマンドを入力してください： ```shell kubectl delete deployment frontend hello From e1bcc4fff9822528597b9338606bda3e3a2ed8b4 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 2 Sep 2020 18:49:36 +0900 Subject: [PATCH 068/303] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- .../access-application-cluster/connecting-frontend-backend.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md index e8af3d5f7a..a1d167c441 100644 --- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -188,7 +188,7 @@ curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えま ## {{% heading "cleanup" %}} -Serviceを削除するために、このコマンドを入力してください： +Serviceを削除するには、このコマンドを入力してください： ```shell kubectl delete services frontend hello @@ -208,4 +208,3 @@ kubectl delete deployment frontend hello - From 9dfe0f044ef4101b1ee4efc181f28fbe95443288 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 1 Sep 2020 12:28:00 +0900 Subject: [PATCH 069/303] updateja/docs/tasks/access-application-cluster/service-access-application-cluster.md --- .../service-access-application-cluster.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index 1fe8e47e7b..ccca616285 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -43,13 +43,8 @@ weight: 60 ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` - このコマンドは - [Deployment](/ja/docs/concepts/workloads/controllers/deployment/) - オブジェクトとそれに紐付く - [ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/) - オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの - [Pod](/ja/docs/concepts/workloads/pods/pod/) - から構成されます。 + このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。 + ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 1. Deploymentの情報を表示します: ```shell From b7e031c621746c0d230d11f8468f27e7b1904800 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 2 Sep 2020 19:01:37 +0900 Subject: [PATCH 070/303] delete newline --- .../service-access-application-cluster.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md index ccca616285..d566f09566 100644 --- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -43,8 +43,7 @@ weight: 60 ```shell kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` - このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。 - ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 + このコマンドは{{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトとそれに紐付く{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つの{{< glossary_tooltip text="Pod" term_id="pod" >}}から構成されます。 1. Deploymentの情報を表示します: ```shell From 1bcce822a1fd64488a2047336d7aae6cc4b36c40 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 23:01:56 +0900 Subject: [PATCH 071/303] Update delete-stateful-set.md --- content/ja/docs/tasks/run-application/delete-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md index 42f22c1b74..659dabec17 100644 --- a/content/ja/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -51,7 +51,7 @@ kubectl delete pods -l app=myapp ### 永続ボリューム -StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが[終了状態](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)になった後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 +StatefulSet内のPodを削除しても、関連付けられているボリュームは削除されません。これは、削除する前にボリュームからデータをコピーする機会があることを保証するためです。Podが終了した後にPVCを削除すると、ストレージクラスと再利用ポリシーによっては、背後にある永続ボリュームの削除がトリガーされることがあります。決してクレーム削除後にボリュームにアクセスできると想定しないでください。 {{< note >}} データを損失する可能性があるため、PVCを削除するときは注意してください。 From eca608559e2f0dbbb7410b7a6d5cfedaa97ea270 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 3 Sep 2020 00:11:10 +0900 Subject: [PATCH 072/303] Update _index.md --- content/ja/docs/tutorials/_index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md index 3d82984243..1c1d55300a 100644 --- a/content/ja/docs/tutorials/_index.md +++ b/content/ja/docs/tutorials/_index.md @@ -1,6 +1,7 @@ --- title: チュートリアル main_menu: true +no_list: true weight: 60 content_type: concept --- @@ -54,6 +55,6 @@ content_type: concept ## {{% heading "whatsnext" %}} -チュートリアルを書きたい場合は、[ページテンプレートの使用](/docs/contribute/style/page-templates/)を参照し、チュートリアルのページタイプとチュートリアルテンプレートについてご確認ください。 +チュートリアルのページタイプについての情報は、[Content Page Types](/docs/contribute/style/page-content-types/)を参照してください。 From 4d361be2b089eb67634e19dbf92aca240ff39ab4 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 11:56:35 +0900 Subject: [PATCH 073/303] Update ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html --- .../ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 602fd843e5..343894e58c 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -40,7 +40,7 @@ weight: 10
-

kubectl runコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。

+

kubectl create deploymentコマンドの--replicasパラメーターを使用することで、最初から複数のインスタンスを含むDeploymentを作成できます。

From eda77a06a3331c871a8119695f68c6a4c06b7e91 Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 30 Aug 2020 19:20:21 +0900 Subject: [PATCH 074/303] modify link title --- .../docs/tasks/debug-application-cluster/debug-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md index 0cafaa28e5..7c8e6eeec8 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -27,7 +27,7 @@ StatefulSetに属し、ラベル`app=myapp`が設定されているすべてのP kubectl get pods -l app=myapp ``` -Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSet Podの強制削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 +Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。 [Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。 From 8c348075d23ff7f0df4288dac3d161febd4386ae Mon Sep 17 00:00:00 2001 From: zettaittenani Date: Thu, 3 Sep 2020 18:53:48 +0900 Subject: [PATCH 075/303] Fix ingress.md's links for ingress controller --- .../concepts/services-networking/ingress.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 26feb3076c..a2e39554c9 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -33,15 +33,15 @@ weight: 40 [ Services ] ``` -IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 +IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。 ## Ingressを使用する上での前提条件 -Ingressを提供するためには[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。 +Ingressを提供するためには[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)が必要です。Ingressリソースを作成するのみでは何の効果もありません。 -[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の中から選択してください。 +[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)のようなIngressコントローラーのデプロイが必要な場合があります。いくつかの[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の中から選択してください。 理想的には、全てのIngressコントローラーはリファレンスの仕様を満たすはずです。しかし実際には、各Ingressコントローラーは微妙に異なる動作をします。 @@ -70,7 +70,7 @@ spec: servicePort: 80 ``` -他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 +他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。 @@ -86,7 +86,7 @@ Ingressコントローラーでは、デフォルトのバックエンドが設 ### デフォルトのバックエンド -ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 +ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 @@ -176,7 +176,7 @@ IngressコントローラーはService(`service1`、`service2`)が存在する 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。 {{< note >}} -使用する[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 +使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 {{< /note >}} ### 名前ベースのバーチャルホスティング @@ -374,7 +374,7 @@ Events: ## アベイラビリティーゾーンをまたいだ障害について -障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。 +障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。 ## 将来追加予定の内容 @@ -390,6 +390,5 @@ Ingressリソースを直接含まない複数の方法でサービスを公開 ## {{% heading "whatsnext" %}} * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ -* [Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers/)について学ぶ +* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ * [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube) - From 3dde44206e4b28ebe8a3c13de4d921c8b26af413 Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Sun, 30 Aug 2020 17:02:26 +0900 Subject: [PATCH 076/303] Update japanese list-all-running-container-images.md to follow v1.18 of the original (English) text --- .../list-all-running-container-images.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3d36d99539..b20a1d77d0 100644 --- a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -25,13 +25,13 @@ weight: 100 - `kubectl get pods --all-namespaces`を使用して、すべての名前空間のPodを取得します - `-o jsonpath={.. image}`を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonの`image`フィールドを再帰的に解析します。 - - jsonpathの使い方については、[jsonpathリファレンス](/docs/user-guide/jsonpath/)を参照してください。 + - jsonpathの使い方については、[jsonpathリファレンス](/docs/reference/kubectl/jsonpath/)を参照してください。 - `tr`、`sort`、`uniq`などの標準ツールを使用して出力をフォーマットします。 - `tr`を使用してスペースを改行に置換します。 - `sort`を使用して結果を並べ替えます。 - `uniq`を使用してイメージ数を集計します。 -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ @@ -42,7 +42,7 @@ uniq -c 別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内で`name`と呼ばれます: -```sh +```shell kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" ``` @@ -61,7 +61,7 @@ jsonpathは次のように解釈されます: `range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -70,7 +70,7 @@ sort 特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 -```sh +```shell kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx ``` @@ -78,7 +78,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx 特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下は`kube-system`名前空間のPodのみに一致します。 -```sh +```shell kubectl get pods --namespace kube-system -o jsonpath="{..image}" ``` @@ -87,7 +87,7 @@ kubectl get pods --namespace kube-system -o jsonpath="{..image}" jsonpathの代わりに、kubectlは[go-templates](https://golang.org/pkg/text/template/)を使用した出力のフォーマットをサポートしています: -```sh +```shell kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" ``` @@ -104,7 +104,7 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r ### 参照 -* [jsonpath](/docs/user-guide/jsonpath/)参照ガイド +* [jsonpath](/docs/reference/kubectl/jsonpath/)参照ガイド * [Go template](https://golang.org/pkg/text/template/)参照ガイド From b03e68d000474dd887cbc5c93beaaadc91d29314 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 12:21:25 +0900 Subject: [PATCH 077/303] Update ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html --- .../tutorials/kubernetes-basics/deploy-app/deploy-intro.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 8bb7a2e6c8..d0b22024b4 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -28,7 +28,7 @@ weight: 10

Kubernetes Deployments

- 実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、KubernetesのDeployment の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、Kubernetesマスターは指定されたアプリケーションインスタンスをクラスター内の個々のノードにスケジュールします。 + 実行中のKubernetesクラスターを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、KubernetesのDeployment の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、KubernetesマスターはDeployment内に含まれるアプリケーションインスタンスをクラスター内の個々のノードで実行するようにスケジュールします。

アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているノードが停止、削除された場合、Deploymentコントローラーはそのインスタンスをクラスター内の別のノード上のインスタンスと置き換えます。これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。

@@ -72,7 +72,7 @@ weight: 10

Kubernetesのコマンドラインインターフェイスであるkubectlを使用して、Deploymentを作成、管理できます。kubectlはKubernetes APIを使用してクラスターと対話します。このモジュールでは、Kubernetesクラスターでアプリケーションを実行するDeploymentを作成するために必要な、最も一般的なkubectlコマンドについて学びます。

-

Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール5と6では、Deploymentをどのようにスケール、更新できるかについて説明します。

+

Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要があります。Deploymentを更新することで、あとでその情報を変更できます。チュートリアルのモジュール5と6では、Deploymentをどのようにスケール、更新できるかについて説明します。

From e7c156a4ffd5fa638bd6e0e1cdbbb603f01d37e8 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 3 Sep 2020 12:08:51 +0900 Subject: [PATCH 078/303] Update ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html --- .../docs/tutorials/kubernetes-basics/expose/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html index ea39fbd94e..3111e67396 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10

Kubernetes Serviceの概要

-

Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、ReplicaSetは、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

+

Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、ReplicaSetは、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML(推奨)またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、LabelSelectorによって決定されます(なぜ仕様にセレクタを含めずにServiceが必要になるのかについては下記を参照してください)。

From a17f9d843be7e9224df41be5f8b43677e77f4078 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 2 Sep 2020 12:12:28 +0900 Subject: [PATCH 079/303] Update ja/docs/tutorials/services/source-ip.md --- .../ja/docs/tutorials/services/source-ip.md | 67 +++++++++---------- 1 file changed, 31 insertions(+), 36 deletions(-) diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md index 69c626d532..05a54152a3 100644 --- a/content/ja/docs/tutorials/services/source-ip.md +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -148,7 +148,7 @@ ip addr そして、`wget`を使用してローカルのウェブサーバーに問い合わせます。 ```shell -# 10.0.170.92 の部分をウェブサーバーのPodのIPv4アドレスに置き換えてください +# "10.0.170.92" の部分をService名が"clusterip"のIPv4アドレスに置き換えてください wget -qO - 10.0.170.92 ``` ``` @@ -176,7 +176,7 @@ service/nodeport exposed ```shell NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` クラウドプロバイダーで実行する場合、上に示した`nodes:nodeport`に対してファイアウォールのルールを作成する必要があるかもしれません。それでは、上で割り当てたノードポート経由で、クラスターの外部からServiceにアクセスしてみましょう。 @@ -204,17 +204,19 @@ client_address=10.240.0.3 図で表すと次のようになります。 -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[Node 2]; + node2-->client; + node2-. SNAT .->node1[Node 1]; + node1-. SNAT .->node2; + node1-->endpoint(Endpoint); + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} クライアントのIPが失われることを回避するために、Kubernetesには[クライアントの送信元IPを保持する](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)機能があります。`service.spec.externalTrafficPolicy`の値を`Local`に設定すると、kube-proxyはローカルに存在するエンドポイントへのプロキシーリクエストだけをプロキシーし、他のノードへはトラフィックを転送しなくなります。このアプローチでは、オリジナルの送信元IPアドレスが保持されます。ローカルにエンドポイントが存在しない場合には、そのノードに送信されたパケットは損失します。そのため、エンドポイントに到達するパケットに適用する可能性のあるパケット処理ルールでは、送信元IPが正しいことを信頼できます。 @@ -253,17 +255,20 @@ client_address=198.51.100.79 図で表すと次のようになります。 -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[Node 1]; + client(client) --x node2[Node 2]; + node1 --> endpoint(endpoint); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} + + ## `Type=LoadBalancer`を使用したServiceでの送信元IP @@ -312,17 +317,7 @@ client_address=10.240.0.5 図で表すと次のようになります。 -``` - client - | - lb VIP - / ^ - v / -ヘルスチェック ---> node 1 node 2 <--- ヘルスチェック - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) アノテーションを設定することで動作をテストできます。 @@ -397,7 +392,7 @@ client_address=198.51.100.79 2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。 -1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 +1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 ## {{% heading "cleanup" %}} From f9469f99d219d5fe56c47b24cff6a6313c24252f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 1 Sep 2020 00:36:36 +0900 Subject: [PATCH 080/303] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index c6b2ff51e8..d504e217fc 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -23,7 +23,7 @@ weight: 10 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 -- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)で参照できます。 +- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. @@ -58,7 +58,7 @@ weight: 10 ### 拡張リソースのためのリソースクォータ -上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)のためのリソースクォータのサポートが追加されました。 +上記で取り上げたリソースに加えて、Kubernetes v1.10において、[拡張リソース](/docs/concepts/configuration/manage-resources-containers/#extended-resources)のためのリソースクォータのサポートが追加されました。 拡張リソースに対するオーバーコミットが禁止されているのと同様に、リソースクォータで拡張リソース用に`requests`と`limits`の両方を指定しても意味がありません。現在、拡張リソースに対しては`requests.`というプレフィックスのついたクォータアイテムのみ設定できます。 @@ -163,7 +163,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース ### PriorityClass毎のリソースクォータ -{{< feature-state for_k8s_version="1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.12" state="beta" >}} Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 @@ -451,7 +451,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ``` ```shell -kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +kubectl create deployment nginx --image=nginx --namespace=myspace ``` ```shell From 011fab911e2c224c430fc57823e7de60fcad3519 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 1 Sep 2020 00:40:56 +0900 Subject: [PATCH 081/303] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index d504e217fc..a58131646c 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -452,6 +452,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ```shell kubectl create deployment nginx --image=nginx --namespace=myspace +kubectl scale deployment nginx --replicas=2 --namespace=myspace ``` ```shell From 44552a817d69ee2db490114d23295207b0b9ce3d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 3 Sep 2020 20:22:25 +0900 Subject: [PATCH 082/303] Update resource-quotas.md --- content/ja/docs/concepts/policy/resource-quotas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index a58131646c..e7368a8f94 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -550,5 +550,5 @@ plugins: ## {{% heading "whatsnext" %}} -さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 +- さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 From c9ed105f44b8d5ebc5a7514d85217fe25fb6f387 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 4 Sep 2020 07:50:32 +0900 Subject: [PATCH 083/303] Update node-conformance.md --- content/ja/docs/setup/best-practices/node-conformance.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/node-conformance.md b/content/ja/docs/setup/best-practices/node-conformance.md index 0db9cb4432..355dfdf366 100644 --- a/content/ja/docs/setup/best-practices/node-conformance.md +++ b/content/ja/docs/setup/best-practices/node-conformance.md @@ -3,7 +3,6 @@ title: ノードのセットアップの検証 weight: 30 --- -{{< toc >}} ## ノード適合テスト From 624d15cdc45cc2614620ff4d92e84589cfa29cd6 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 28 Aug 2020 12:52:49 +0900 Subject: [PATCH 084/303] Updata content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md --- .../configure-access-multiple-clusters.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 2dc61d16a9..28fe1fdeaa 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -21,7 +21,9 @@ card: ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つ以内のバージョン](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 @@ -306,7 +308,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` ### Windows Powershell ```shell -$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config) +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME/.kube/config" ``` `KUBECONFIG`環境変数内のファイルからまとめられた設定情報を確認してください。`config-exercise`ディレクトリ内から、以下のコマンドを実行してください: @@ -319,11 +321,11 @@ kubectl config view `KUBECONFIG`環境変数を元に戻してください。例えば: -Linux: +### Linux: ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` -Windows PowerShell +### Windows PowerShell ```shell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` From 3cbdf975301f67a8e6d3b9ab65d697fd21b620a0 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 31 Aug 2020 12:19:40 +0900 Subject: [PATCH 085/303] Apply suggestions from code review Co-authored-by: Keita Akutsu --- .../configure-access-multiple-clusters.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 28fe1fdeaa..072fc36cf2 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つ以内のバージョン](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)にある必要があります。 @@ -337,4 +337,3 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED * [kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - From 5848086102d46989b67d44557e7cb07815c33f84 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 11:56:57 +0900 Subject: [PATCH 086/303] fix some words --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 072fc36cf2..c85ef1f401 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスタのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)にある必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 From 7b627c522913132c3f6be8ab7fa97784d9df4309 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 4 Sep 2020 19:27:02 +0900 Subject: [PATCH 087/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../configure-access-multiple-clusters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index c85ef1f401..b2ebc16d18 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -23,7 +23,7 @@ card: {{< include "task-tutorial-prereqs.md" >}} -{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}がインストールされているか確認するため、`kubectl version --client`を実行してください。kubectlのバージョンは、クラスターのAPIサーバーの[1つのマイナーバージョン内](/ja/docs/setup/release/version-skew-policy/#kubectl)である必要があります。 From edb89f7f8f8baa14e34a4af3dd9f48948f5d0b93 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Fri, 4 Sep 2020 22:53:54 +0900 Subject: [PATCH 088/303] Fix typo in Ja concepts/overview/what-is-kubernetes.md Fixed typo for word "stateless". --- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 5f2f4bbf18..aeaca7940e 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -75,7 +75,7 @@ Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシス Kubernetesは... -* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 +* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。 * ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。 * ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。 * ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。 From 64813947bd964c2063b7410ac66a5e44827761b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:01:27 +0900 Subject: [PATCH 089/303] Update ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html --- .../kubernetes-basics/deploy-app/deploy-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 4af01cc759..71e04ef76b 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20

- Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。 + Podは、Kubernetesアプリケーションの基本的な実行単位です。各Podは、クラスターで実行されているワークロードの一部を表します。Podの詳細はこちらです。

From cb0f2a951944d983a507b5b6317018045d314c4b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 5 Sep 2020 02:04:03 +0900 Subject: [PATCH 090/303] Update certificates.md --- .../ja/docs/setup/best-practices/certificates.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/content/ja/docs/setup/best-practices/certificates.md b/content/ja/docs/setup/best-practices/certificates.md index 7f67ee7006..7fbf4bf8b8 100644 --- a/content/ja/docs/setup/best-practices/certificates.md +++ b/content/ja/docs/setup/best-practices/certificates.md @@ -26,10 +26,10 @@ Kubernetesは下記の用途でPKIを必要とします： * APIサーバーがetcdと通信するためのクライアント証明書 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig -* [front-proxy][proxy]用のクライアント証明書およびサーバー証明書 +* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用のクライアント証明書およびサーバー証明書 {{< note >}} -`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。 +`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/extend-kubernetes/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。 {{< /note >}} さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。 @@ -52,7 +52,7 @@ kubeadmで証明書を生成したくない場合は、下記の方法のいず |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | Kubernetes全体の認証局　　　 | | etcd/ca.crt,key | etcd-ca | etcd用　　　　　　　　　　　　　　 | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy]用　　　 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 | 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。 @@ -72,9 +72,9 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全 | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) +[1]: クラスターに接続するIPおよびDNS名( [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`) -`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます: +`kind`は下記の[x509の鍵用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)のタイプにマッピングされます: | 種類 | 鍵の用途 　　　 | |--------|---------------------------------------------------------------------------------| @@ -96,7 +96,8 @@ kubeadm利用者のみ： ### 証明書のパス -証明書は推奨パスに配置するべきです([kubeadm][kubeadm]を使用する場合と同様)。パスは場所に関係なく与えられた引数で特定されます。 +証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。 +パスは場所に関係なく与えられた引数で特定されます。 | デフォルトCN | 鍵の推奨パス 　　　　　　 | 証明書の推奨パス 　　　　　 | コマンド | 鍵を指定する引数 | 証明書を指定する引数 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| @@ -157,8 +158,5 @@ KUBECONFIG= kubectl config use-context default-system | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 | | scheduler.conf | kube-scheduler | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。 | -[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage -[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ From 24dcb7b206cb6cfa28b537084c198f0de4bfe282 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Mon, 7 Sep 2020 07:05:04 +0900 Subject: [PATCH 091/303] fix diagonal line mark up of "replication" --- content/ja/docs/concepts/workloads/pods/pod-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 76e8f11a62..4d286fdbcf 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -33,7 +33,7 @@ Kubernetesクラスター内でのPodは2つの主な方法で使うことがで * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns) 各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。 -Kubernetesにおいて、これは一般的に_レプリケーション_ と呼ばれます。 +Kubernetesにおいて、これは一般的に _レプリケーション_ と呼ばれます。 レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。 さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。 From 60ba9f697db66821e6e2d85c083a14a1a269954f Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:08:30 +0900 Subject: [PATCH 092/303] Update ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html --- .../kubernetes-basics/create-cluster/cluster-interactive.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 8f260a0831..ae52322786 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -19,7 +19,7 @@ weight: 20
- ターミナルを使うには、PCまたはタブレットをお使いください + ターミナルを使うにはスクリーンが狭い場合は、PCまたはタブレットをお使いください
From 58cb155fd89e0ef55ff2452673c917140602d6ab Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 6 Sep 2020 22:53:17 +0900 Subject: [PATCH 093/303] Update _index.md --- content/ja/docs/setup/_index.md | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 2d602e9300..4b6e930170 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -17,12 +17,11 @@ card: このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。 +Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。 -各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。 -Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。 +Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。 -簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。 @@ -30,25 +29,14 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの ## 環境について学ぶ -Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。 +Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。 -{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}} - -|コミュニティ |エコシステム | -| ------------ | -------- | -| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| -| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | -| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| -| | [k3s](https://k3s.io)| ## 本番環境 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 From a59c29be1a8cb70144c00cb187e3dce10b021dd5 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 6 Sep 2020 23:20:18 +0900 Subject: [PATCH 094/303] Update _index.md --- content/ja/docs/setup/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/_index.md b/content/ja/docs/setup/_index.md index 4b6e930170..6f7153f445 100644 --- a/content/ja/docs/setup/_index.md +++ b/content/ja/docs/setup/_index.md @@ -37,6 +37,6 @@ Kubernetesについて学んでいる場合、Kubernetesコミュニティにサ 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。 -[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。 +[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。 From 2cc1ced9d5657cfa34848d61a1b69da51459272c Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 15:44:21 +0900 Subject: [PATCH 095/303] Update Japanese localization on concepts/workloads/controllers/daemonset.md --- .../workloads/controllers/daemonset.md | 50 ++++++++----------- 1 file changed, 22 insertions(+), 28 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index a985ccf2fa..d6df9e2f83 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -2,7 +2,7 @@ reviewers: title: DaemonSet content_type: concept -weight: 50 +weight: 40 --- @@ -11,12 +11,11 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー DaemonSetのいくつかの典型的な使用例は以下の通りです。 -- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。 -- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。 -- [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)や[Flowmill](https://github.com/Flowmill/flowmill-k8s/)、[Sysdig Agent](https://docs.sysdig.com)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、 [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration)、Gangliaの`gmond`、[Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)や[Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)などのようなNodeのモニタリングデーモンを各Node上で稼働させる。 +- クラスターのストレージデーモンを全てのNode上で稼働させる。 +- ログ集計デーモンを全てのNode上で稼働させる。 +- Nodeのモニタリングデーモンを全てのNode上で稼働させる。 -シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。 -さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 +シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。 @@ -27,8 +26,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。 ### DaemonSetの作成 -ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。 -例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 +ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。 {{< codenew file="controllers/daemonset.yaml" >}} @@ -40,8 +38,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 必須のフィールド -他の全ての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/)、[コンテナの設定](/ja/docs/tasks/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。 DaemonSetオブジェクトの名前は、有効な [DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 @@ -52,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な `.spec.template`は`.spec`内での必須のフィールドの1つです。 -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、[Pod](/ja/docs/concepts/workloads/pods/pod/)のテンプレートと同じスキーマとなります。 +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 @@ -60,7 +57,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts ### Podセレクター -`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)の`.spec.selector`と同じものです。 +`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 @@ -75,11 +72,10 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。 -### 特定のいくつかのNode上のみにPodを稼働させる +### 選択したNode上でPodを稼働させる もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node -selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。 -同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/configuration/assign-pod-node/)マッチするPodをNode上に作成します。 +selector](/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするPodをNode上に作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/)マッチするPodをNode上に作成します。 もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。 ## Daemon Podがどのようにスケジューリングされるか @@ -94,7 +90,7 @@ DaemonSetは全ての利用可能なNodeが単一のPodのコピーを稼働さ * 矛盾する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が存在するとき、それは新しいものに置き換えられます。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 +`ScheduleDaemonSetPods`は、DaemonSetのPodに対して`NodeAffinity`項目を追加することにより、DaemonSetコントローラーの代わりにデフォルトスケジューラーを使ってDaemonSetのスケジュールを可能にします。その際に、デフォルトスケジューラーはPodをターゲットのホストにバインドします。もしDaemonSetのNodeAffinityが存在するとき、それは新しいものに置き換えられます(ターゲットホストを選択する前に、元のNodeAffinityが考慮されます)。DaemonSetコントローラーはDaemonSetのPodの作成や修正を行うときのみそれらの操作を実施します。そしてDaemonSetの`.spec.template`フィールドに対しては何も変更が加えられません。 ```yaml nodeAffinity: @@ -111,17 +107,16 @@ nodeAffinity: ### TaintsとTolerations -DaemonSetのPodは[TaintsとTolerations](/docs/concepts/configuration/taint-and-toleration)の設定を尊重します。 -下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 +DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。 -| 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)します。 +| 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)します。 | ## Daemon Podとのコミュニケーション @@ -158,8 +153,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd` ### 静的Pod Pods -Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/concepts/cluster-administration/static-pod/)と呼ばれます。 -DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 +Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。 ### Deployment From 372bcd7b72b4b15e8e4f663d4ab05f97556612dc Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:49:41 +0900 Subject: [PATCH 096/303] Update content/ja/docs/concepts/workloads/controllers/daemonset.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index d6df9e2f83..7787871650 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -49,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な `.spec.template`は`.spec`内での必須のフィールドの1つです。 -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 +`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。 Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。 @@ -162,4 +162,3 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 - From 427a7e8782752cc682d26b21c64524cb8be910cf Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 7 Sep 2020 13:03:48 +0900 Subject: [PATCH 097/303] Update ja/docs/reference/glossary/control-plane.md --- content/ja/docs/reference/glossary/control-plane.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index 1153d68db8..b1d30ae76c 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -11,3 +11,15 @@ tags: - fundamental --- コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。 + + + + このレイヤーは、次のような多くの異なるコンポーネントから構成されます。（しかし、これらに限定はされません） + + * {{< glossary_tooltip text="etcd" term_id="etcd" >}} + * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} + + これらのコンポーネントは従来のオペレーティングシステムサービス（デーモン）もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 4e87c9e701a46d477829b68bcfd3fdbc42eb01cf Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 9 Sep 2020 12:03:22 +0900 Subject: [PATCH 098/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/control-plane.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index b1d30ae76c..46796ef8d0 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -14,7 +14,7 @@ tags: - このレイヤーは、次のような多くの異なるコンポーネントから構成されます。（しかし、これらに限定はされません） + このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。 * {{< glossary_tooltip text="etcd" term_id="etcd" >}} * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} @@ -22,4 +22,4 @@ tags: * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} - これらのコンポーネントは従来のオペレーティングシステムサービス（デーモン）もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 + これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 530a85cbe2c22ec5f5dce2c6896e1372075b328d Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 9 Sep 2020 12:51:19 +0900 Subject: [PATCH 099/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/control-plane.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/reference/glossary/control-plane.md b/content/ja/docs/reference/glossary/control-plane.md index 46796ef8d0..00fd3ab3e3 100644 --- a/content/ja/docs/reference/glossary/control-plane.md +++ b/content/ja/docs/reference/glossary/control-plane.md @@ -17,9 +17,9 @@ tags: このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。 * {{< glossary_tooltip text="etcd" term_id="etcd" >}} - * {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} - * {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}} - * {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}} - * {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}} + * {{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="コントローラーマネージャー" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="クラウドコントローラーマネージャー" term_id="cloud-controller-manager" >}} これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的に{{< glossary_tooltip text="マスター" term_id="master" >}}と呼ばれていました。 From 7df4ce95e0daa2da028599ea0c02021c37851da2 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 22:42:51 +0900 Subject: [PATCH 100/303] Update Japanese localization on tasks/administer-cluster/running-cloud-controller.md --- .../running-cloud-controller.md | 25 +++++++------------ 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index 9a06821517..3ef031b252 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -1,15 +1,15 @@ --- -title: Kubernetesクラウドコントローラーマネージャー +title: クラウドコントローラーマネージャー運用 content_type: concept --- -{{< feature-state state="beta" >}} +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -Kubernetes v1.6では`cloud-controller-manager`という新しいバイナリが導入されました。`cloud-controller-manager`はクラウド固有の制御ループを組み込むデーモンです。これらのクラウド固有の制御ループはもともと`kube-controller-manager`にありました。クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを`cloud-controller-manager`バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。 +クラウドプロバイダーはKubernetesプロジェクトとは異なるペースで開発およびリリースされるため、プロバイダー固有のコードを{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}}バイナリに抽象化することでクラウドベンダーはKubernetesのコアのコードとは独立して開発が可能となりました。 -`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。今後のKubernetesのリリースでは、すべてのクラウドコントローラーマネージャーはsigリードまたはクラウドベンダーが管理するKubernetesのコアプロジェクトの外で開発される予定です。 +`cloud-controller-manager`は、[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす任意のクラウドプロバイダーと接続できます。下位互換性のためにKubernetesのコアプロジェクトで提供される[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)は`kube-controller-manager`と同じクラウドライブラリを使用します。Kubernetesのコアリポジトリですでにサポートされているクラウドプロバイダーは、Kubernetesリポジトリにあるcloud-controller-managerを使用してKubernetesのコアから移行することが期待されています。 @@ -38,7 +38,7 @@ cloud-controller-managerを正常に実行するにはクラスター構成に * `--cloud-provider=external`を指定したkubeletは、初期化時に`NoSchedule`の`node.cloudprovider.kubernetes.io/uninitialized`汚染を追加します。これによりノードは作業をスケジュールする前に外部のコントローラーからの2回目の初期化が必要であるとマークされます。クラウドコントローラーマネージャーが使用できない場合クラスター内の新しいノードはスケジュールできないままになることに注意してください。スケジューラーはリージョンやタイプ(高CPU、GPU、高メモリ、スポットインスタンスなど)などのノードに関するクラウド固有の情報を必要とする場合があるためこの汚染は重要です。 * クラスター内のノードに関するクラウド情報はローカルメタデータを使用して取得されなくなりましたが、代わりにノード情報を取得するためのすべてのAPI呼び出しはクラウドコントローラーマネージャーを経由して行われるようになります。これはセキュリティを向上させるためにkubeletでクラウドAPIへのアクセスを制限できることを意味します。大規模なクラスターではクラスター内からクラウドのほとんどすべてのAPI呼び出しを行うため、クラウドコントローラーマネージャーがレートリミットに達するかどうかを検討する必要があります。 -v1.8の時点でクラウドコントローラーマネージャーは以下を実装できます。 +クラウドコントローラーマネージャーは以下を実装できます。 * ノードコントローラー - クラウドAPIを使用してkubernetesノードを更新し、クラウドで削除されたkubernetesノードを削除します。 * サービスコントローラー - タイプLoadBalancerのサービスに対応してクラウド上のロードバランサーを操作します。 @@ -52,12 +52,6 @@ v1.8の時点でクラウドコントローラーマネージャーは以下を Kubernetesのコアリポジトリにないクラウドコントローラーマネージャーの場合、クラウドベンダーまたはsigリードが管理するリポジトリでプロジェクトを見つけることができます。 -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [keepalived](https://github.com/munnerz/keepalived-cloud-provider) -* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager) -* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager) - - すでにKubernetesのコアリポジトリにあるプロバイダーの場合、クラスター内でデーモンセットとしてKubernetesリポジトリ内部のクラウドコントローラーマネージャーを実行できます。以下をガイドラインとして使用してください。 {{< codenew file="admin/cloud/ccm-example.yaml" >}} @@ -73,18 +67,17 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### スケーラビリティ -クラウドプロバイダーの以前のアーキテクチャではローカルメタデータサービスを使用して自身のノード情報を取得するkubeletに依存していました。新しいアーキテクチャではクラウドコントローラーマネージャーがすべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 +cloud-controller-managerは、クラウドプロバイダーのAPIにクエリを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 ### 鶏と卵 クラウドコントローラーマネージャープロジェクトの目標はKubernetesのコアプロジェクトからクラウドに関する機能の開発を切り離すことです。残念ながら、Kubernetesプロジェクトの多くの面でクラウドプロバイダーの機能がKubernetesプロジェクトに緊密に結びついているという前提があります。そのため、この新しいアーキテクチャを採用するとクラウドプロバイダーの情報を要求する状況が発生する可能性がありますが、クラウドコントローラーマネージャーはクラウドプロバイダーへのリクエストが完了するまでその情報を返すことができない場合があります。 -これの良い例は、KubeletのTLSブートストラップ機能です。現在、TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 +これの良い例は、KubeletのTLSブートストラップ機能です。TLSブートストラップはKubeletがすべてのアドレスタイプ(プライベート、パブリックなど)をクラウドプロバイダー(またはローカルメタデータサービス)に要求する能力を持っていると仮定していますが、クラウドコントローラーマネージャーは最初に初期化されない限りノードのアドレスタイプを設定できないためapiserverと通信するためにはkubeletにTLS証明書が必要です。 このイニシアチブが成熟するに連れ、今後のリリースでこれらの問題に対処するための変更が行われます。 -## 独自のクラウドコントローラマネージャーを開発する - -独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)のドキュメントを参照してください。 +## {{% heading "whatsnext" %}} +独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。 From f7517161e33e0be78cf0a4b120e19c84ac1a0e4a Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:45:37 +0900 Subject: [PATCH 101/303] Update content/ja/docs/tasks/administer-cluster/running-cloud-controller.md Co-authored-by: inductor(Kohei) --- .../docs/tasks/administer-cluster/running-cloud-controller.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index 3ef031b252..a32b6acc86 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -1,5 +1,5 @@ --- -title: クラウドコントローラーマネージャー運用 +title: クラウドコントローラーマネージャーの運用管理 content_type: concept --- @@ -80,4 +80,3 @@ cloud-controller-managerは、クラウドプロバイダーのAPIにクエリ ## {{% heading "whatsnext" %}} 独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。 - From a2e11b741fb615afe47c77ae04307aa07f0ea849 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 12:46:16 +0900 Subject: [PATCH 102/303] Update content/ja/docs/tasks/administer-cluster/running-cloud-controller.md Co-authored-by: nasa9084 --- .../docs/tasks/administer-cluster/running-cloud-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md index a32b6acc86..04dfd62f8b 100644 --- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md @@ -67,7 +67,7 @@ Kubernetesのコアリポジトリにないクラウドコントローラーマ ### スケーラビリティ -cloud-controller-managerは、クラウドプロバイダーのAPIにクエリを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 +cloud-controller-managerは、クラウドプロバイダーのAPIにクエリーを送信して、すべてのノードの情報を取得します。非常に大きなクラスターの場合、リソース要件やAPIレートリミットなどのボトルネックの可能性を考慮する必要があります。 ### 鶏と卵 From 320648440e2af578f3e60c071da4bd98e40bc0a5 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 11 Sep 2020 17:33:58 +0900 Subject: [PATCH 103/303] Update Japanese localization on tutorials/stateful-application/mysql-wordpress-persistent-volume.md --- .../stateful-application/mysql-wordpress-persistent-volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 7aed33777e..5e7b77443d 100644 --- a/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -188,8 +188,8 @@ kubectl apply -k ./ 結果は次のようになるはずです。 ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} From e5e8415840199a3a5844f9388b2c07f266e1b71a Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 12 Sep 2020 20:14:14 +0900 Subject: [PATCH 104/303] update links --- .../api-extension/apiserver-aggregation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 3a14aab62c..50593a61b8 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -32,9 +32,9 @@ kube-apiserverとの間を5秒以内に往復するためには、ディスカ ## {{% heading "whatsnext" %}} -* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します -* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します -* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい +* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)します +* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/extend-kubernetes/setup-extension-api-server/)します +* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)方法を学んで下さい * [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)の仕様をお読み下さい From 32a72991f75945dcf177c3ef3929f2fe38c80069 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:39:07 +0900 Subject: [PATCH 105/303] Make docs/tasks/configure-pod-container/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/configure-pod-container/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/configure-pod-container/_index.md b/content/ja/docs/tasks/configure-pod-container/_index.md index 94b5079fa8..324a19b22b 100755 --- a/content/ja/docs/tasks/configure-pod-container/_index.md +++ b/content/ja/docs/tasks/configure-pod-container/_index.md @@ -1,5 +1,6 @@ --- title: "Podとコンテナの設定" +description: Podとコンテナの一般的な設定のタスクを行います。 weight: 20 --- From 4a50a07a3fb2f83159d47b3f345ab5ef6f3b1b9e Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:28:01 +0900 Subject: [PATCH 106/303] Make docs/tasks/access-application-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/access-application-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/access-application-cluster/_index.md b/content/ja/docs/tasks/access-application-cluster/_index.md index dda8899f73..dc48e62246 100755 --- a/content/ja/docs/tasks/access-application-cluster/_index.md +++ b/content/ja/docs/tasks/access-application-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "クラスター内アプリケーションへのアクセス" +description: クラスター内アプリケーションへアクセスできるようにするために、ロードバランシングやポートフォワーディングの設定、ファイアウォールやDNS設定のセットアップを行います。 weight: 60 --- From fd31e94f02aa268cf7a6b44dfee196eabc1adb5f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 8 Sep 2020 19:10:05 +0900 Subject: [PATCH 107/303] translated what-is-kubernetes.md --- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index aeaca7940e..d1b792c0da 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -71,7 +71,7 @@ Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密 ## Kubernetesにないもの -Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散、ロギングやモニタリングといったPasSが提供するのと共通の機能をいくつか提供しています。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 +Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。 Kubernetesは... From 866fe31acb3b19a4af7e2ca73b80a01cc0b40ab2 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:17:49 +0900 Subject: [PATCH 108/303] Make docs/tasks/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/_index.md | 78 +-------------------------------- 1 file changed, 2 insertions(+), 76 deletions(-) diff --git a/content/ja/docs/tasks/_index.md b/content/ja/docs/tasks/_index.md index 758500260b..6352ae67b1 100644 --- a/content/ja/docs/tasks/_index.md +++ b/content/ja/docs/tasks/_index.md @@ -5,82 +5,8 @@ weight: 50 content_type: concept --- -{{< toc >}} - -Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。 -タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 - - - - - -## Web UI (ダッシュボード) - -ダッシュボードWeb UIを展開してアクセスし、Kubernetesクラスター内のコンテナ化されたアプリケーションの管理と監視に役立てます。 - -## kubectlコマンドラインツールの使用 - -Kubernetesクラスターを直接管理するために使用される`kubectl`コマンドラインツールをインストールしてセットアップします。 - -## Podとコンテナの設定 - -Podとコンテナの一般的な設定タスクを実行します。 - -## アプリケーションの実行 - -ローリングアップデート、Podへの情報の注入、水平Podオートスケーリングなど、一般的なアプリケーション管理タスクを実行します。 - -## ジョブの実行 - -並列処理を使用してジョブを実行します。 - -## クラスター内のアプリケーションへのアクセス - -クラスター内のアプリケーションにアクセスするために、負荷分散、ポート転送を設定するか、ファイアウォールまたはDNSの設定をセットアップします。 - -## 監視、ログ、デバッグ - -クラスタのトラブルシューティングまたはコンテナ化されたアプリケーションのデバッグのために、監視とログを設定します。 - -## Kubernetes APIへのアクセス - -Kubernetes APIに直接アクセスするためのさまざまな方法を学びます。 - -## TLSの使用 - -クラスタールート認証局(CA)を信頼して使用するようにアプリケーションを設定します。 - -## クラスターの管理 - -クラスターを管理するための一般的なタスクを学びます。 - -## フェデレーションの管理 - -クラスタフェデレーションのコンポーネントを設定します。 - -## ステートフルなアプリケーションの管理 - -StatefulSetのスケーリング、削除、デバッグなど、ステートフルなアプリケーションを管理するための一般的なタスクを実行します。 - -## クラスターデーモン - -ローリングアップデートの実行など、DaemonSetを管理するための一般的なタスクを実行します。 - -## GPUの管理 - -クラスター内のノードがリソースとして使用するNVIDIA GPUを設定およびスケジュールします。 - -## Huge Pageの管理 - -クラスター内のスケジュール可能なリソースとしてHuge Pageを構成およびスケジュールします。 - - - -## {{% heading "whatsnext" %}} - - -タスクページを作成する場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 - +Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 +タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 From 037e108865fe2089fd4a1483780b8799074164ee Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sun, 13 Sep 2020 19:17:05 +0900 Subject: [PATCH 109/303] Update the link Co-authored-by: Naoki Oketani --- content/ja/docs/tasks/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/_index.md b/content/ja/docs/tasks/_index.md index 6352ae67b1..b90950aea8 100644 --- a/content/ja/docs/tasks/_index.md +++ b/content/ja/docs/tasks/_index.md @@ -9,4 +9,4 @@ content_type: concept Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。 -タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/home/contribute/create-pull-request/)を参照してください。 +タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/contribute/new-content/open-a-pr/)を参照してください。 From 65612f2c68e9f4d605c29cc52235e5d06ad9ad11 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Tue, 1 Sep 2020 00:17:07 +0900 Subject: [PATCH 110/303] finish translate --- content/ja/docs/concepts/containers/_index.md | 31 ++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index 3e1c30f9b8..af34967521 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -1,4 +1,33 @@ --- -title: "コンテナ" +title: コンテナ weight: 40 +description: アプリケーションと依存関係のあるランタイムを一緒にパッケージ化するための技術 +reviewers: +content_type: concept +no_list: true --- + + + +実行するそれぞれのコンテナは繰り返し使用可能で、依存関係を含めた形式で規格化されていることは、どこで実行しても同じ動作が得られることを意味しています。 + +コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。 + + + + + + +## コンテナイメージ +[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 + +設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 + +## コンテナランタイム + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。 +* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。 From f2dd2b515ec6a68bd1ea816866043d5c963c58c6 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Tue, 8 Sep 2020 23:42:07 +0900 Subject: [PATCH 111/303] Update content/ja/docs/concepts/containers/_index.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/containers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index af34967521..f64bad4796 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -1,7 +1,7 @@ --- title: コンテナ weight: 40 -description: アプリケーションと依存関係のあるランタイムを一緒にパッケージ化するための技術 +description: アプリケーションとランタイムの依存関係を一緒にパッケージ化するための技術 reviewers: content_type: concept no_list: true From 7dd5550b0656f9a3c5625528f9ee7361af8f6e49 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Wed, 9 Sep 2020 23:32:30 +0900 Subject: [PATCH 112/303] Update content/ja/docs/concepts/containers/_index.md Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/containers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index f64bad4796..5b10416c0f 100755 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -9,7 +9,7 @@ no_list: true -実行するそれぞれのコンテナは繰り返し使用可能で、依存関係を含めた形式で規格化されていることは、どこで実行しても同じ動作が得られることを意味しています。 +実行するそれぞれのコンテナは繰り返し使用可能です。依存関係を含めて標準化されており、どこで実行しても同じ動作が得られることを意味しています。 コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。 From 744e475fff71fede4152419c632c8efb3f613e19 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 9 Sep 2020 20:08:32 +0900 Subject: [PATCH 113/303] translated common-labels.md --- .../concepts/overview/working-with-objects/common-labels.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md index 9212de948e..ee7e88eccd 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/common-labels.md @@ -26,7 +26,7 @@ content_type: concept | キー | 説明 | 例 | 型 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | アプリケーション名 | `mysql` | 文字列 | -| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `wordpress-abcxzy` | 文字列 | +| `app.kubernetes.io/instance` | アプリケーションのインスタンスを特定するための固有名 | `mysql-abcxzy` | 文字列 | | `app.kubernetes.io/version` | アプリケーションの現在のバージョン (例: セマンティックバージョン、リビジョンのハッシュなど) | `5.7.21` | 文字列 | | `app.kubernetes.io/component` | アーキテクチャ内のコンポーネント | `database` | 文字列 | | `app.kubernetes.io/part-of` | このアプリケーションによって構成される上位レベルのアプリケーション | `wordpress` | 文字列 | @@ -40,7 +40,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress From 1bafdfee0344f645c227057a0808f9de33de109f Mon Sep 17 00:00:00 2001 From: arisgi Date: Sun, 13 Sep 2020 23:54:17 +0900 Subject: [PATCH 114/303] Translate docs/concepts/configuration/overview.md into Japanese --- content/ja/docs/concepts/configuration/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 2a5dfc4a51..14304bbc71 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -31,7 +31,7 @@ weight: 10 - 可能な限り、"真っ裸"のPod([ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。 - 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。 + 明示的に[`restartPolicy: Never`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略(RollingUpdateなど)を指定したりできます。[Job](/docs/concepts/workloads/controllers/job/)のほうが適切な場合もあるかもしれません。 ## Service @@ -68,11 +68,11 @@ weight: 10 ## コンテナイメージ -[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/admin/kubelet/)が特定のイメージをpullしようとしたときに作用します。 +[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/reference/command-line-tools-reference/kubelet/)が特定のイメージをpullしようとしたときに作用します。 - `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。 -- `imagePullPolicy: Always`: Podの起動時に常にイメージをpullします。 +- `imagePullPolicy: Always`: kubeletがコンテナを起動する度に、kubeletはコンテナイメージレジストリに問い合わせて、イメージのダイジェストの名前解決を行います。もし、kubeletが同じダイジェストのコンテナイメージをローカルにキャッシュしていたら、kubeletはそのキャッシュされたイメージを利用します。そうでなければ、kubeletは解決されたダイジェストのイメージをダウンロードし、そのイメージを利用してコンテナを起動します。 - `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグが`:latest`の場合や省略されている場合、`Always`が適用されます。 @@ -98,6 +98,6 @@ weight: 10 - `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。 - +- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment` や `kubectl expose` を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 From a59e157940e900d99ddd08af70859b72010f6d7f Mon Sep 17 00:00:00 2001 From: arisgi Date: Mon, 14 Sep 2020 01:02:09 +0900 Subject: [PATCH 115/303] Remove unnecessary spaces --- content/ja/docs/concepts/configuration/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 14304bbc71..5f2fd15120 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -98,6 +98,6 @@ weight: 10 - `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。 -- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment` や `kubectl expose` を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 +- 単一コンテナのDeploymentやServiceを素早く作成するなら、`kubectl create deployment`や`kubectl expose`を使いましょう。一例として、[Serviceを利用したクラスター内のアプリケーションへのアクセス](/docs/tasks/access-application-cluster/service-access-application-cluster/)を参照してください。 From ae96a7aca9b2e8300d287bcd8333b8c129e75766 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 21 Aug 2020 11:38:20 +0900 Subject: [PATCH 116/303] Update Japanese localization on concepts/containers/container-lifecycle-hooks.md --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 13ad6f2578..9f1a94af45 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 ### フックハンドラーの実装 From 9297d8dbaa40196e23979bed2097f54897e2e78f Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 8 Sep 2020 10:31:28 +0900 Subject: [PATCH 117/303] Update content/ja/docs/concepts/containers/container-lifecycle-hooks.md Co-authored-by: Naoki Oketani --- .../ja/docs/concepts/containers/container-lifecycle-hooks.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index 9f1a94af45..ba94bd6fab 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -34,7 +34,7 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 ### フックハンドラーの実装 @@ -102,4 +102,3 @@ Events: * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン - From e21280f19e5b98d6b7324800c174bea8fb8feb21 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Mon, 7 Sep 2020 13:20:56 +0900 Subject: [PATCH 118/303] update nodes.md for v1.18 --- .../ja/docs/concepts/architecture/nodes.md | 207 +++++++++++------- 1 file changed, 124 insertions(+), 83 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 1c3d47c019..c2f74f9566 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -6,27 +6,107 @@ weight: 10 -ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/ja/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。 - - +Kubernetesはコンテナをノード上で実行されるPodに配置することで、ワークロードを実行します。 +ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。 +各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。 +通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。 +1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。 +## 管理 {#management} + +ノードを{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}に加えるには2つの方法があります: + +1. ノード上のkubeletが、コントロールプレーンに自己登録する。 +2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。 + +Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう。 + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetesは内部的にNodeオブジェクトを作成します。 APIサーバーに登録したkubeletがノードの`metadata.name`フィールドが一致しているか検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 + +{{< note >}} +Kubernetesは無効なNodeのオブジェクトを保持し、それが有効になるまで検証を続けます。 + +ヘルスチェックを止めるためには、あなた、もしくは{{< glossary_tooltip term_id="controller" text="コントローラー">}}が明示的にNodeを削除する必要があります。 +{{< /note >}} + +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +### ノードの自己登録 {#self-registration-of-nodes} + +kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。 + +自己登録については、kubeletは以下のオプションを伴って起動されます: + + - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス + - `--cloud-provider` - 自身に関するメタデータを読むために{{< glossary_tooltip text="クラウドプロバイダー" term_id="cloud-provider" >}}と会話する方法 + - `--register-node` - 自身をAPIサーバーに自動的に登録 + - `--register-with-taints` - 与えられた{{< glossary_tooltip text="taint" term_id="taint" >}}のリストでノードを登録します (カンマ区切りの `=:`)。 + + `register-node`がfalseの場合、このオプションは機能しません + - `--node-ip` - ノードのIPアドレス + - `--node-labels` - ノードをクラスターに登録するときに追加する{{< glossary_tooltip text="Label" term_id="label" >}}（[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照） + - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定 + +[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。 + +### 手動によるノード管理 {#manual-node-administration} + +クラスター管理者は{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}を使用してNodeオブジェクトを作成および変更できます。 + +管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。 + +管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。 +変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。 + +ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。 +例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。 + +ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。 +これは、ノードの再起動などの前の準備ステップとして役立ちます。 + +ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します: + +```shell +kubectl cordon $ノード名 +``` + +{{< note >}} +{{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。 +これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンセットがマシンに属していることを前提としているためです。 +{{< /note >}} + ## ノードのステータス -ノードのステータスには以下のような情報が含まれます: +ノードのステータスは以下の情報を含みます: * [Addresses](#addresses) * [Conditions](#condition) * [CapacityとAllocatable](#capacity) * [Info](#info) -ノードのステータスや、ノードに関するその他の詳細は、下記のコマンドを使うことで表示できます: +`kubectl`を使用し、ノードのステータスや詳細を確認できます: + ```shell -kubectl describe node <ノード名> +kubectl describe node <ノード名をここに挿入> ``` -各セクションについては、下記で説明します。 + +出力情報の各箇所について、以下で説明します。 ### Addresses @@ -41,15 +121,22 @@ kubectl describe node <ノード名> `conditions`フィールドは全ての`Running`なノードのステータスを表します。例として、以下のような状態を含みます: -| ノードのCondition | 概要 | -|----------------|-------------| -| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | -| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | -| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | -| `DiskPressure` | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 | -| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 | +{{< table caption = "ノードのConditionと、各condition適用時の概要" >}} +| ノードのCondition | 概要 | +|----------------------|-------------| +| `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | +| `DiskPressure` | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 | +| `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | +| `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | +| `NetworkUnavailable` | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 | +{{< /table >}} -ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のようなレスポンスが表示されます。 +{{< note >}} +コマンドラインを使用してcordonされたNodeを表示する場合、Conditionは`SchedulingDisabled`を含みます。 +`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。 +{{< /note >}} + +ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。 ```json "conditions": [ @@ -64,14 +151,15 @@ kubectl describe node <ノード名> ] ``` -Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。 +Ready conditionが`pod-eviction-timeout`({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に渡された引数)に設定された時間を超えても`Unknown`や`False`のままになっている場合、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodは切り離されたノードの上で稼働を続けることになります。 -バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 - -ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 +ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を自動的に生成します。 スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 +詳細は[条件によるtaintの付与](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)を参照してください。 + ### CapacityとAllocatable {#capacity} ノードで利用可能なリソース（CPU、メモリ、およびノードでスケジュールできる最大Pod数）について説明します。 @@ -115,7 +203,7 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ### ノードコントローラー -ノードコントローラーは、ノードのさまざまな側面を管理するKubernetesのマスターコンポーネントです。 +ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。 ノードコントローラーは、ノードの存続期間中に複数の役割を果たします。1つ目は、ノードが登録されたときにCIDRブロックをノードに割り当てることです（CIDR割り当てがオンになっている場合）。 @@ -140,10 +228,6 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担 #### 信頼性 - -Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） -バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 - ほとんどの場合、排除の速度は1秒あたり`--node-eviction-rate`に設定された数値（デフォルトは秒間0.1）です。つまり、10秒間に1つ以上のPodをノードから追い出すことはありません。 特定のアベイラビリティーゾーン内のノードのステータスが異常になると、ノード排除の挙動が変わります。ノードコントローラーは、ゾーン内のノードの何%が異常（NodeReady条件がConditionUnknownまたはConditionFalseである）であるかを同時に確認します。 @@ -156,51 +240,8 @@ Kubernetes 1.4では、マスターに問題が発生した場合の対処方法 コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。 -Kubernetes 1.6以降では、ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。 -さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。 -`NoExecute`のtaint及び上述のアルファ機能に関する詳細は、[こちらのドキュメント](/docs/concepts/configuration/taint-and-toleration/)をご覧ください。 - -バージョン1.8以降、ノードコントローラーに対してノードの状態を表すtaintを作成する責務を持たせることができます。これはバージョン1.8のアルファ機能です。 - -### ノードの自己登録 - -kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。 - -自己登録については、kubeletは以下のオプションを伴って起動されます: - - - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス - - `--cloud-provider` - 自身に関するメタデータを読むためにクラウドプロバイダーと会話する方法 - - `--register-node` - 自身をAPIサーバーに自動的に登録 - - `--register-with-taints` - 与えられたtaintのリストでノードを登録します (カンマ区切りの `=:`). `register-node`がfalseの場合、このオプションは機能しません - - `--node-ip` - ノードのIPアドレス - - `--node-labels` - ノードをクラスターに登録するときに追加するラベル（1.13以降の[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照） - - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定 - -[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。 - -#### 手動によるノード管理 {#manual-node-administration} - -クラスター管理者はNodeオブジェクトを作成および変更できます。 - -管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。 - -管理者は`--register-node`の設定に関係なくNodeリソースを変更することができます。 -変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。 - -ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。 -例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。 - -ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。 -これは、ノードの再起動などの前の準備ステップとして役立ちます。たとえば、ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します: - -```shell -kubectl cordon $ノード名 -``` - -{{< note >}} -DaemonSetコントローラーによって作成されたPodはKubernetesスケジューラーをバイパスし、ノード上のunschedulable属性を考慮しません。 -これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 -{{< /note >}} +ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。 +さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。 {{< caution >}} `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという @@ -209,29 +250,29 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ ### ノードのキャパシティ -ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 -通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。 +Nodeオブジェクトはノードのリソースキャパシティ（CPUの数とメモリの量）を監視します。 +[自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。 [手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。 -Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。 +Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。 ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。 -これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/ja/docs/concepts/overview/components/#container-runtime)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。 +これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。 -Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +{{< note >}} +Pod以外のプロセス用にリソースを明示的に予約したい場合は、[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)を参照してください。 +{{< /note >}} ## ノードのトポロジー -{{< feature-state state="alpha" >}} +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} `TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 - -## APIオブジェクト - -NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: -[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). - +詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。 ## {{% heading "whatsnext" %}} -* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 -* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。 +* [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。 +* アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。 +* [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。 +* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。 From cbba4077b29f1adaf808dd51ac11cd4231a10af7 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 8 Sep 2020 23:08:10 +0900 Subject: [PATCH 119/303] update nodes.md for v1.18 --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index c2f74f9566..72879fa525 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -6,7 +6,7 @@ weight: 10 -Kubernetesはコンテナをノード上で実行されるPodに配置することで、ワークロードを実行します。 +Kubernetesはコンテナを_Node_上で実行されるPodに配置することで、ワークロードを実行します。 ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。 各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。 From bfeee745f3d632d6a600abcb82d97941c9f03274 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 8 Sep 2020 23:12:32 +0900 Subject: [PATCH 120/303] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 72879fa525..05793ebde8 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -88,7 +88,7 @@ kubectl cordon $ノード名 {{< note >}} {{< glossary_tooltip term_id="daemonset" >}}によって作成されたPodはノード上のunschedulable属性を考慮しません。 -これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンセットがマシンに属していることを前提としているためです。 +これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、DaemonSetがマシンに属していることを前提としているためです。 {{< /note >}} ## ノードのステータス From 1641b7e34c50b11fe80ec16a43c231c7c0b5615d Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Sat, 5 Sep 2020 22:12:29 +0900 Subject: [PATCH 121/303] fix translation for "such as" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In the context, "Development, Staging and Production" is example, so I think "といった" is appropriate. --- .../docs/concepts/overview/working-with-objects/namespaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 1b66e046f1..12de8e10df 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -79,7 +79,7 @@ kubectl config view --minify | grep namespace: ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。 このエントリは`..svc.cluster.local`という形式になり、これはもしあるコンテナがただ``を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。 -これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。 +これはデベロップメント、ステージング、プロダクションといった複数のNamespaceをまたいで同じ設定を使う時に効果的です。 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。 ## すべてのオブジェクトはNamespaceに属しているとは限らない From 067dc0603962850a97f89066dcf0a2f484b45147 Mon Sep 17 00:00:00 2001 From: Tadaki Sakai Date: Tue, 8 Sep 2020 21:15:05 +0900 Subject: [PATCH 122/303] fix mark up in Ja concepts/workloads/controllers/deployment.md --- .../ja/docs/concepts/workloads/controllers/deployment.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index 6b4fe79264..6f0f481add 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -13,7 +13,7 @@ weight: 30 _Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。 -Deploymentにおいて_理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 +Deploymentにおいて _理想的な状態_ を記述すると、Deployment{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 {{< note >}} Deploymentによって作成されたReplicaSetを管理しないでください。ご自身のユースケースが以下の項目に含まれない場合、メインのKubernetesリポジトリーにIssueを作成することを検討してください。 @@ -110,7 +110,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください ReplicaSetの出力には次のフィールドが表示されます: * `NAME`は、名前空間内にあるReplicaSetの名前の一覧です。 - * `DESIRED`は、アプリケーションの理想的な_レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。 + * `DESIRED`は、アプリケーションの理想的な _レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが _理想的な状態_ と呼ばれるものです。 * `CURRENT`は現在実行されているレプリカの数です。 * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。 * `AGE`は、アプリケーションが稼働してからの時間です。 @@ -756,7 +756,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し ### Deploymentの更新処理 {#progressing-deployment} -以下のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。 +以下のタスクが実行中のとき、KubernetesはDeploymentの状態を _進行中_ にします。 * Deploymentが新しいReplicaSetを作成します。 * Deploymentが新しいReplicaSetをスケールアップさせています。 @@ -767,7 +767,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し ### Deploymentの更新処理の完了 {#complete-deployment} -Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。 +Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを _完了_ にします。 * Deploymentの全てのレプリカが、指定された最新のバージョンに更新されます。これは指定した更新処理が完了したことを意味します。 * Deploymentの全てのレプリカが利用可能になります。 From db611d74af7e2e81d751059ea50caef8b07ac35d Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:33:52 +0900 Subject: [PATCH 123/303] Make docs/tasks/administer-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/administer-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/administer-cluster/_index.md b/content/ja/docs/tasks/administer-cluster/_index.md index 0f075ca038..b7a34be8db 100755 --- a/content/ja/docs/tasks/administer-cluster/_index.md +++ b/content/ja/docs/tasks/administer-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "クラスターの管理" +description: クラスターの管理のための一般的なタスクについて学びます。 weight: 20 --- From 4a40397bc365350a2e5bc5f95874531e059be5b2 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Fri, 28 Aug 2020 21:27:49 +0900 Subject: [PATCH 124/303] Update ttlafterfinished.md --- .../concepts/workloads/controllers/ttlafterfinished.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index d1b1cc3354..ca68ddcac0 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -2,7 +2,7 @@ reviewers: title: 終了したリソースのためのTTLコントローラー(TTL Controller for Finished Resources) content_type: concept -weight: 65 +weight: 70 --- @@ -10,7 +10,7 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 -TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 +TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 @@ -23,7 +23,7 @@ TTLコントローラーは現在[Job](/docs/concepts/workloads/controllers/jobs ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 023b0dd9687678a3bd0230ca7fc0fbcfbeb93059 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 00:27:09 +0900 Subject: [PATCH 125/303] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index ca68ddcac0..1715f2cf91 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 239cf338d747d0a1ac40ae1716f8eb3aa27298e0 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 29 Aug 2020 10:17:44 +0900 Subject: [PATCH 126/303] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 1715f2cf91..daa98ebc01 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 949260c0e455d4ed757b7f15ea333babfec9099f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 00:08:24 +0900 Subject: [PATCH 127/303] Update ttlafterfinished.md --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index daa98ebc01..01af87c553 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](/#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 0377d7ba37cc8d939fedd283fcf20bde997f774c Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 00:32:11 +0900 Subject: [PATCH 128/303] fixed hashtag link --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 01af87c553..0c7c233fcd 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](#終了したjobの自動クリーンアップ) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 536d49174a2cbd19f234d29d82fd1a2e15992840 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:13:48 +0900 Subject: [PATCH 129/303] fixed link --- content/ja/docs/concepts/workloads/controllers/job.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md index 386eb1dd5c..9bc827f5c4 100644 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ b/content/ja/docs/concepts/workloads/controllers/job.md @@ -230,7 +230,7 @@ Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workl `restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 -## 終了したJobの自動クリーンアップ +## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} 終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 From cd78bc4b070b36ad215477c411ed9b3e77185655 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:14:17 +0900 Subject: [PATCH 130/303] Revert "fixed link" This reverts commit 175f6974b86b7b5b11711402b5e4f66d8f6b6264. --- .../concepts/workloads/controllers/job.md | 387 ------------------ 1 file changed, 387 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md deleted file mode 100644 index 9bc827f5c4..0000000000 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ /dev/null @@ -1,387 +0,0 @@ ---- -title: Job -content_type: concept -feature: - title: バッチ実行 - description: > - Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 -weight: 60 ---- - - - -Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 -JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 - -簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 -ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 - -また、Jobを使用して複数のPodを並行して実行することもできます。 - - - - - - -## Jobの実行例 - -ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 -完了までに10秒程度かかります。 - -{{< codenew file="controllers/job.yaml" >}} - -このコマンドで例を実行できます。 - -```shell -kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml -``` -``` -job.batch/pi created -``` - -Jobのステータスは、`kubectl`を用いて確認します。 - -```shell -kubectl describe jobs/pi -``` -``` -Name: pi -Namespace: default -Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c -Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi -Annotations: kubectl.kubernetes.io/last-applied-configuration: - {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... -Parallelism: 1 -Completions: 1 -Start Time: Mon, 02 Dec 2019 15:20:11 +0200 -Completed At: Mon, 02 Dec 2019 15:21:16 +0200 -Duration: 65s -Pods Statuses: 0 Running / 1 Succeeded / 0 Failed -Pod Template: - Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi - Containers: - pi: - Image: perl - Port: - Host Port: - Command: - perl - -Mbignum=bpi - -wle - print bpi(2000) - Environment: - Mounts: - Volumes: -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 -``` - -Jobの完了したPodを表示するには、`kubectl get pods`を使います。 - -あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 - -```shell -pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') -echo $pods -``` -``` -pi-5rwd7 -``` - -ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 - - -いずれかのPodの標準出力を表示します。 - -```shell -kubectl logs $pods -``` -出力例は以下の通りです。 -```shell -3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 -``` - -## Jobの仕様の作成 - -他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 -その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 - -Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 - -### Podテンプレート - -`.spec.template`は、`.spec`の唯一の必須フィールドです。 - -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 -ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 - -Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 - -`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 - -### Podセレクター {#pod-selector} - -`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 -セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 - - -### Jobの並列実行 {#parallel-jobs} - -Jobとして実行するのに適したタスクは、大きく分けて3つあります。 - -1. 非並列Job - - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 - - そのPodが正常に終了するとすぐにJobが完了します。 -2. *固定の完了数*を持つ並列Job - - `.spec.completions`に、0以外の正の値を指定します。 - - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 - - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 -3. *ワークキュー*を持つ並列Job - - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 - - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 - - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 - - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 - - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 - - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 - -_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 - -_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 - - -様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 - -#### 並列処理の制御 - -並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 -指定しない場合、デフォルトで1になります。 -0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 - -以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 - -- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 -- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 -- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 -- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 -- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 -- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 - -## Podおよびコンテナの障害の処理 - -Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 -`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 - -さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 - -たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 - -`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 - -### Pod Backoff Failure Policy - -構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 -そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 -失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 -JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 - -{{< note >}} -Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 -{{< /note >}} - -## Jobの終了とクリーンアップ - -Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 -Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 - -デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 - -Jobを終了する別の方法は、アクティブな期限を設定することです。 -これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します -`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 -Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 - -Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 - -以下に例を挙げます。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-timeout -spec: - backoffLimit: 5 - activeDeadlineSeconds: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 - -`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 -つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 - -## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} - -終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 - -### 終了したJobのTTLメカニズム - -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} - -完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 - -TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 - -例は以下の通りです。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-ttl -spec: - ttlSecondsAfterFinished: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 - -フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 - -このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 - -## Jobのパターン {#job-patterns} - -Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 - -例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 - -複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 - -並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 -トレードオフは以下の通りです。 - -- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 -- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 -- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 - -ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 -パターン名は、例とより詳細な説明へのリンクでもあります。 - -| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | -| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | -| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | - -完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 - -以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 -ここで、`W`はワークアイテム数とします。 - -| パターン名 | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | -| 単一のJob静的な処理を割り当てる | W | 任意 | - - -## 高度な使用方法 - -### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} - -通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 -システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 -セレクターの値は、他のJobと重複しないように選択されます。 - -しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 -これを行うには、Jobの`.spec.selector`を指定します。 - -これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 -もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 - -ここでは、この機能を使いたくなるようなケースの例をご紹介します。 -`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 -これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 -そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 -削除する前に、どのセレクターを使っているかメモしておきます。 - -``` -kubectl get job old -o yaml -``` -``` -kind: Job -metadata: - name: old - ... -spec: - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` -次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 -既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 - -システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 - -``` -kind: Job -metadata: - name: new - ... -spec: - manualSelector: true - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` - -新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 -`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 - -## 代替案 - -### ベアPod - -Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 -このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 - -### レプリケーションコントローラー - -Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 -レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 - -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 -(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) - -### 単一のJobでコントローラーPodを起動 - -もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 - -このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 - -このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 - -## Cron Job {#cron-jobs} - -Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From 2135d79e7c2a5a370d3558c29de14bfb4454d600 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:15:01 +0900 Subject: [PATCH 131/303] fixed link --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 0c7c233fcd..1715f2cf91 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -23,7 +23,7 @@ TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" ## TTLコントローラー -TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](#終了したjobの自動クリーンアップ)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 +TTLコントローラーは現在Jobに対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。 @@ -50,7 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](#終了したjobの自動クリーンアップ) +[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From 6c1601c26e326579365c7941ab0e80288971e316 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:18:06 +0900 Subject: [PATCH 132/303] pulled job.md from master and added english heading title --- .../concepts/workloads/controllers/job.md | 387 ++++++++++++++++++ 1 file changed, 387 insertions(+) create mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000..9bc827f5c4 --- /dev/null +++ b/content/ja/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,387 @@ +--- +title: Job +content_type: concept +feature: + title: バッチ実行 + description: > + Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 +weight: 60 +--- + + + +Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 +JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 + +簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 +ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 + +また、Jobを使用して複数のPodを並行して実行することもできます。 + + + + + + +## Jobの実行例 + +ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 +完了までに10秒程度かかります。 + +{{< codenew file="controllers/job.yaml" >}} + +このコマンドで例を実行できます。 + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` +``` +job.batch/pi created +``` + +Jobのステータスは、`kubectl`を用いて確認します。 + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + job-name=pi + Containers: + pi: + Image: perl + Port: + Host Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 +``` + +Jobの完了したPodを表示するには、`kubectl get pods`を使います。 + +あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-5rwd7 +``` + +ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 + + +いずれかのPodの標準出力を表示します。 + +```shell +kubectl logs $pods +``` +出力例は以下の通りです。 +```shell +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Jobの仕様の作成 + +他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 +その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 + +### Podテンプレート + +`.spec.template`は、`.spec`の唯一の必須フィールドです。 + +`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 +ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 + +Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 + +`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 + +### Podセレクター {#pod-selector} + +`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 +セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 + + +### Jobの並列実行 {#parallel-jobs} + +Jobとして実行するのに適したタスクは、大きく分けて3つあります。 + +1. 非並列Job + - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 + - そのPodが正常に終了するとすぐにJobが完了します。 +2. *固定の完了数*を持つ並列Job + - `.spec.completions`に、0以外の正の値を指定します。 + - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 + - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 +3. *ワークキュー*を持つ並列Job + - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 + - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 + - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 + - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 + - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 + - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 + +_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 + +_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 + + +様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 + +#### 並列処理の制御 + +並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 +指定しない場合、デフォルトで1になります。 +0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 + +以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 + +- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 +- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 +- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 +- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 +- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 +- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 + +## Podおよびコンテナの障害の処理 + +Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 +`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 + +さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 + +たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 + +`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 + +### Pod Backoff Failure Policy + +構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 +そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 +失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 +JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 + +{{< note >}} +Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 +{{< /note >}} + +## Jobの終了とクリーンアップ + +Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 +Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 + +デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 + +Jobを終了する別の方法は、アクティブな期限を設定することです。 +これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します +`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 +Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 + +Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 + +以下に例を挙げます。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 + +`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 +つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 + +## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} + +終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 + +### 終了したJobのTTLメカニズム + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 + +TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 + +例は以下の通りです。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 + +フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 + +このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 + +## Jobのパターン {#job-patterns} + +Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 + +例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 + +複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 + +並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 +トレードオフは以下の通りです。 + +- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 +- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 +- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 + +ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 +パターン名は、例とより詳細な説明へのリンクでもあります。 + +| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | +| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | + +完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 + +以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 +ここで、`W`はワークアイテム数とします。 + +| パターン名 | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | +| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | +| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | +| 単一のJob静的な処理を割り当てる | W | 任意 | + + +## 高度な使用方法 + +### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} + +通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 +システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 +セレクターの値は、他のJobと重複しないように選択されます。 + +しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 +これを行うには、Jobの`.spec.selector`を指定します。 + +これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 +もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 + +ここでは、この機能を使いたくなるようなケースの例をご紹介します。 +`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 +これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 +そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 +削除する前に、どのセレクターを使っているかメモしておきます。 + +``` +kubectl get job old -o yaml +``` +``` +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` +次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 +既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 + +システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 + +``` +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 +`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 + +## 代替案 + +### ベアPod + +Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 +このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 + +### レプリケーションコントローラー + +Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 +レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 + +[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 +(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) + +### 単一のJobでコントローラーPodを起動 + +もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 + +このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 + +このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 + +## Cron Job {#cron-jobs} + +Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From 3f20b116b1e61b09b1de9b82527082af97a9ac1f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 30 Aug 2020 13:49:27 +0900 Subject: [PATCH 133/303] Revert "pulled job.md from master and added english heading title" This reverts commit 1756223848ce5a10ce8a2d90df6a5fd8e90cc61b. --- .../concepts/workloads/controllers/job.md | 387 ------------------ 1 file changed, 387 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/controllers/job.md diff --git a/content/ja/docs/concepts/workloads/controllers/job.md b/content/ja/docs/concepts/workloads/controllers/job.md deleted file mode 100644 index 9bc827f5c4..0000000000 --- a/content/ja/docs/concepts/workloads/controllers/job.md +++ /dev/null @@ -1,387 +0,0 @@ ---- -title: Job -content_type: concept -feature: - title: バッチ実行 - description: > - Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。 -weight: 60 ---- - - - -Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。 -JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。 - -簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。 -ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。 - -また、Jobを使用して複数のPodを並行して実行することもできます。 - - - - - - -## Jobの実行例 - -ここでは、Jobの設定例を示します。πの値を2000桁目まで計算して出力します。 -完了までに10秒程度かかります。 - -{{< codenew file="controllers/job.yaml" >}} - -このコマンドで例を実行できます。 - -```shell -kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml -``` -``` -job.batch/pi created -``` - -Jobのステータスは、`kubectl`を用いて確認します。 - -```shell -kubectl describe jobs/pi -``` -``` -Name: pi -Namespace: default -Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c -Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi -Annotations: kubectl.kubernetes.io/last-applied-configuration: - {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":... -Parallelism: 1 -Completions: 1 -Start Time: Mon, 02 Dec 2019 15:20:11 +0200 -Completed At: Mon, 02 Dec 2019 15:21:16 +0200 -Duration: 65s -Pods Statuses: 0 Running / 1 Succeeded / 0 Failed -Pod Template: - Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c - job-name=pi - Containers: - pi: - Image: perl - Port: - Host Port: - Command: - perl - -Mbignum=bpi - -wle - print bpi(2000) - Environment: - Mounts: - Volumes: -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7 -``` - -Jobの完了したPodを表示するには、`kubectl get pods`を使います。 - -あるJobに属するすべてのPodの一覧を機械可読な形式で出力するには、次のようなコマンドを使います。 - -```shell -pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') -echo $pods -``` -``` -pi-5rwd7 -``` - -ここでのセレクターは、Jobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストの各Podから名前だけを取得する式を指定します。 - - -いずれかのPodの標準出力を表示します。 - -```shell -kubectl logs $pods -``` -出力例は以下の通りです。 -```shell -3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 -``` - -## Jobの仕様の作成 - -他のすべてのKubernetesの設定と同様に、Jobには`apiVersion`、`kind`、および`metadata`フィールドが必要です。 -その名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 - -Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 - -### Podテンプレート - -`.spec.template`は、`.spec`の唯一の必須フィールドです。 - -`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。 -ネストされており、`apiVersion`や`kind`ないことを除けば、{{< glossary_tooltip text="Pod" term_id="pod" >}}とまったく同じスキーマを持ちます。 - -Podの必須フィールドに加えて、JobのPodテンプレートでは、適切なラベル([Podセレクター](#pod-selector)参照)と適切な再起動ポリシーを指定しなければなりません。 - -`Never`または`OnFailure`と等しい[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のみが許可されます。 - -### Podセレクター {#pod-selector} - -`.spec.selector`フィールドはオプションです。ほとんどの場合、指定すべきではありません。 -セクション「[独自のPodセレクターの指定](#specifying-your-own-pod-selector)」を参照してください。 - - -### Jobの並列実行 {#parallel-jobs} - -Jobとして実行するのに適したタスクは、大きく分けて3つあります。 - -1. 非並列Job - - 通常は、Podが失敗しない限り、1つのPodのみが起動されます。 - - そのPodが正常に終了するとすぐにJobが完了します。 -2. *固定の完了数*を持つ並列Job - - `.spec.completions`に、0以外の正の値を指定します。 - - Jobはタスク全体を表し、1から`.spec.completions`の範囲内の各値に対して、1つの成功したPodがあれば完了です。 - - **まだ実装されていません**が、各Podには、1から`.spec.completions`の範囲内で異なるインデックスが渡されます。 -3. *ワークキュー*を持つ並列Job - - `.spec.completions`は指定しません。デフォルトは`.spec.parallelism`です。 - - Podは、それぞれが何を処理するか決定するために、 Pod間または外部サービス間で調整する必要があります。例えば、あるPodはワークキューから最大N個のアイテムのバッチを取得します。 - - 各Podはすべてのピアが完了したかどうか、つまりJob全体が完了したかどうかを、独立して判断できます。 - - Jobの _任意の_ Podが正常終了すると、新しいPodは作成されません。 - - 少なくとも1つのPodが正常終了し、すべてのPodが終了すると、Jobは正常に完了します。 - - Podが正常終了した後は、他のPodがこのタスクの処理を行ったり、出力を書き込んだりしてはなりません。それらはすべて終了する必要があります。 - -_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにすることができます。両方が設定されていない場合、どちらもデフォルトで1になります。 - -_ワークキュー_ を持つJobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負整数にする必要があります。 - - -様々な種類のJobを利用する方法の詳細については、セクション「[Jobのパターン](#job-patterns)」をご覧ください。 - -#### 並列処理の制御 - -並列処理数(`.spec.parallelism`)については、任意の非負整数を設定できます。 -指定しない場合、デフォルトで1になります。 -0を指定した場合、並列処理数が増えるまで、Jobは実質的に一時停止されます。 - -以下に挙げる様々な理由から、実際の並列処理数(任意の時点で実行されるPodの数)が、要求された数より多い場合と少ない場合があります。 - -- _固定完了数_ を持つJobの場合、並行して実行されるPodの実際の数は、残りの完了数を超えることはありません。`.spec.parallelism`の大きい値は事実上無視されます。 -- _ワークキュー_ を持つJobの場合、Podが成功しても新しいPodは開始されません。ただし、残りのPodは完了できます。 -- Jobコントローラー({{< glossary_tooltip term_id="controller" >}})が反応する時間がない場合も考えられます。 -- Jobコントローラーが何らかの理由(`ResourceQuota`がない、権限がないなど)でPodの作成に失敗した場合、要求された数よりも少ないPod数になる可能性があります。 -- Jobコントローラーは、同じJob内で以前のPodが過剰に失敗したために、新しいPodの作成を調整する場合があります。 -- Podをグレースフルにシャットダウンした場合、停止までに時間がかかります。 - -## Podおよびコンテナの障害の処理 - -Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリー制限を超えたためにコンテナが強制終了されたなど、さまざまな理由で失敗する可能性があります。これが発生し、`.spec.template.spec.restartPolicy = "OnFailure"`であ場合、Podはノードに残りますが、コンテナは再実行されます。したがって、プログラムはローカルで再起動するケースを処理するか、`.spec.template.spec.restartPolicy = "Never"`を指定する必要があります。 -`restartPolicy`の詳細な情報は、[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/#example-states)を参照してください。 - -さまざまな理由で、Pod全体が失敗することもあります。例えば、Podが(ノードのアップグレード、再起動、削除などにより)ノードから切り離された場合や、Podのコンテナが失敗して`.spec.template.spec.restartPolicy = "Never"`が設定されている場合などです。Podが失敗した場合、Jobコントローラーは新しいPodを開始します。つまり、アプリケーションは新しいPodで再起動されたケースを処理する必要があります。特に、前の実行によって発生した一時ファイル、ロック、不完全な出力などに対する処理が必要です。 - -たとえ`.spec.parallelism = 1`、`.spec.completions = 1`、`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動される場合があることに注意してください。 - -`.spec.parallelism`と`.spec.completions`の両方を1より大きい値に指定した場合は、複数のPodが同時に実行される可能性があります。したがって、Podは同時実行性にも対応する必要があります。 - -### Pod Backoff Failure Policy - -構成の論理エラーなどが原因で、ある程度の再試行後にJobを失敗させたい場合があります。 -そのためには、`.spec.backoffLimit`を設定して、Jobが失敗したと見なすまでの再試行回数を指定します。デフォルトでは6に設定されています。 -失敗したPodは、6分を上限とする指数バックオフ遅延(10秒、20秒、40秒...)に従って、Jobコントローラーにより再作成されます。 -JobのPodが削除されるか、Jobの他のPodがその時間に失敗することなく成功すると、バックオフカウントがリセットされます。 - -{{< note >}} -Jobに`restartPolicy = "OnFailure"`がある場合、Jobのバックオフ制限に達すると、Jobを実行しているコンテナが終了することに注意してください。これにより、Jobの実行可能ファイルのデバッグがより困難になる可能性があります。Jobのデバッグするまたはロギングシステムを使用する場合は、`restartPolicy = "Never"`を設定して、失敗したJobからの出力が誤って失われないようにすることをお勧めします。 -{{< /note >}} - -## Jobの終了とクリーンアップ - -Jobが完了すると、Podは作成されなくなりますが、Podの削除も行われません。それらを保持しておくと、完了したPodのログを表示して、エラー、警告、またはその他の診断の出力を確認できます。 -Jobオブジェクトは完了後も残るため、ステータスを表示できます。ステータスを確認した後、古いJobを削除するのはユーザーの責任です。`kubectl`(例えば`kubectl delete jobs/pi`や`kubectl delete -f ./job.yaml`)を用いてJobを削除してください。`kubectl`でJobを削除すると、Jobが作成したすべてのPodも削除されます。 - -デフォルトでは、Podが失敗する(`restartPolicy=Never`)かコンテナがエラーで終了する(`restartPolicy=OnFailure`)場合を除き、Jobは中断されずに実行されます。その時点でJobは上記の`.spec.backoffLimit`に従います。`.spec.backoffLimit`に達すると、Jobは失敗としてマークされ、実行中のPodはすべて終了されます。 - -Jobを終了する別の方法は、アクティブな期限を設定することです。 -これを行うには、Jobの`.spec.activeDeadlineSeconds`フィールドを秒数に設定します -`activeDeadlineSeconds`は、作成されたPodの数に関係なく、Jobの期間に適用されます。 -Jobが`activeDeadlineSeconds`に到達すると、実行中のすべてのPodが終了し、Jobのステータスは`type: Failed`および`reason: DeadlineExceeded`となります。 - -Jobの`.spec.activeDeadlineSeconds`は、`.spec.backoffLimit`よりも優先されることに注意してください。したがって、1つ以上の失敗したPodを再試行しているJobは、`backoffLimit`にまだ達していない場合でも、`activeDeadlineSeconds`で指定された制限時間に達すると、追加のPodをデプロイしません。 - -以下に例を挙げます。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-timeout -spec: - backoffLimit: 5 - activeDeadlineSeconds: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job内のJobの仕様と[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)の両方に`activeDeadlineSeconds`フィールドがあることに注意してください。このフィールドが適切なレベルに設定されていることを確認してください。 - -`restartPolicy`はPodに適用され、Job自体には適用されないことに注意してください。Jobのステータスが`type: Failed`になると、Jobの自動再起動は行われません。 -つまり、 `.spec.activeDeadlineSeconds`と`.spec.backoffLimit`でアクティブ化されるJob終了のメカニズムは、手作業での介入が必要になるような永続的なJobの失敗を引き起こします。 - -## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically} - -終了したJobは、通常、もう必要ありません。それらをシステム内に保持すると、APIサーバーに負担がかかります。[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)などの上位レベルのコントローラーによってJobが直接管理されている場合、指定された容量ベースのクリーンアップポリシーに基づいて、JobをCronJobsでクリーンアップできます。 - -### 終了したJobのTTLメカニズム - -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} - -完了したJob(`Complete`または`Failed`)を自動的にクリーンアップする別の方法は、[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が提供するTTLメカニズムを使用して、完了したリソースを指定することです。Jobの`.spec.ttlSecondsAfterFinished`フィールドに指定します。 - -TTLコントローラーがJobをクリーンアップすると、Jobが連鎖的に削除されます。つまり、Podなどの依存オブジェクトがJobとともに削除されます。Jobが削除されるとき、ファイナライザーなどのライフサイクル保証が優先されることに注意してください。 - -例は以下の通りです。 - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: pi-with-ttl -spec: - ttlSecondsAfterFinished: 100 - template: - spec: - containers: - - name: pi - image: perl - command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] - restartPolicy: Never -``` - -Job`pi-with-ttl`は、Jobが終了してから`100`秒後に自動的に削除される。 - -フィールドが`0`に設定されている場合は、Jobは終了後すぐに自動的に削除されます。フィールドが設定されていない場合は、このJobは終了後にTTLコントローラーによってクリーンアップされません。 - -このTTLメカニズムはアルファ版であり、`TTLAfterFinished`フィーチャーゲートであることに注意してください。詳細は[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)のドキュメントを参照してください。 - -## Jobのパターン {#job-patterns} - -Jobオブジェクトは、Podの信頼性の高い並列実行をサポートするために使用できます。Jobオブジェクトは、科学的コンピューティングで一般的に見られるような、密接に通信する並列プロセスをサポートするようには設計されていません。しかし、独立しているが関連性のある*ワークアイテム*の集合の並列処理はサポートしています。 - -例えば送信する電子メール、レンダリングするフレーム、トランスコードするファイル、スキャンするNoSQLデータベースのキーの範囲などです。 - -複雑なシステムでは、複数の異なるワークアイテムの集合があるかもしれません。ここでは、ユーザーがまとめて管理したい作業項目の1つの集合(バッチJob)を考えています。 - -並列計算にはいくつかのパターンがあり、それぞれ長所と短所があります。 -トレードオフは以下の通りです。 - -- 各ワークアイテムに1つのJobオブジェクトを使用する場合と、すべてのワークアイテムに1つのJobオブジェクトを使用する場合を比較すると、後者の方がワークアイテムの数が多い場合に適しています。前者では、ユーザーとシステムが大量のJobオブジェクトを管理するためのオーバーヘッドが発生します。 -- 作成されたPodの数がワークアイテムの数に等しい場合と、各Podが複数のワークアイテムを処理する場合を比較すると、前者の方が一般的に既存のコードやコンテナへの変更が少ないです。後者は上記の項目と同様の理由で、大量のワークアイテムを処理するのに適しています。 -- いくつかのアプローチでは、ワークキューを使用します。これはキューサービスを実行している必要があり、既存のプログラムやコンテナを変更してワークキューを使用するようにする必要があります。他のアプローチは、既存のコンテナ化されたアプリケーションに適応するのがさらに容易です。 - -ここでは、上記のトレードオフに対応するものを、2から4列目にまとめています。 -パターン名は、例とより詳細な説明へのリンクでもあります。 - -| パターン名 | 単一のJobオブジェクト | ワークアイテムよりPodが少ないか？ | アプリをそのまま使用するか？ | Kube 1.1で動作するか？ | -| ----------------------------------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 場合による | ✓ | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | -| 単一のJob静的な処理を割り当てる | ✓ | | ✓ | | - -完了数を`.spec.completions`で指定すると、Jobコントローラーが作成した各Podは同じ[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。つまり、あるタスクを実行するすべてのPodは、同じコマンドラインと同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持ちます。これらのパターンは、Podが異なる処理を行うように配置するための様々な方法です。 - -以下の表では、パターンごとに必要な`.spec.parallelism`と`.spec.completions`の設定を示します。 -ここで、`W`はワークアイテム数とします。 - -| パターン名 | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------------------------------------------------------------- |:-------------------:|:--------------------:| -| [Jobテンプレートを拡張する](/ja/docs/tasks/job/parallel-processing-expansion/) | 1 | 1とする必要あり | -| [ワークアイテムごとにPodでキューを作成する](/ja/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 | -| [Pod数が可変であるキューを作成する](/ja/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 | -| 単一のJob静的な処理を割り当てる | W | 任意 | - - -## 高度な使用方法 - -### 独自のPodセレクターを指定する {#specifying-your-own-pod-selector} - -通常、Jobオブジェクトを作成する際には`.spec.selector`を指定しません。 -システムのデフォルトのロジックで、Jobの作成時にこのフィールドを追加します。 -セレクターの値は、他のJobと重複しないように選択されます。 - -しかし、場合によっては、この自動的に設定されるセレクターを上書きする必要があるかもしれません。 -これを行うには、Jobの`.spec.selector`を指定します。 - -これを行う際には十分に注意が必要です。もし指定したラベルセレクターが、そのJobのPodに対して固有でなく、無関係なPodにマッチする場合、無関係なJobのPodが削除されたり、このJobが他のPodを完了したものとしてカウントしたり、一方または両方のJobがPodの作成や完了まで実行を拒否することがあります。 -もし固有でないセレクターを選択した場合は、他のコントローラー(例えばレプリケーションコントローラーなど)やそのPodも予測不能な動作をする可能性があります。Kubernetesは`.spec.selector`を指定する際のミスを防ぐことはできません。 - -ここでは、この機能を使いたくなるようなケースの例をご紹介します。 -`old`というJobがすでに実行されているとします。既存のPodを実行し続けたいが、作成した残りのPodには別のPodテンプレートを使用し、Jobには新しい名前を付けたいとします。 -これらのフィールドは更新が不可能であるため、Jobを更新することはできません。 -そのため、`kubectl delete jobs/old --cascade=false`を使って、`old`というJobを削除し、一方で _そのPodは実行したまま_ にします。 -削除する前に、どのセレクターを使っているかメモしておきます。 - -``` -kubectl get job old -o yaml -``` -``` -kind: Job -metadata: - name: old - ... -spec: - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` -次に`new`という名前の新しいJobを作成し、同じセレクターを明示的に指定します。 -既存のPodには`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`というラベルが付いているので、それらも同様にJob`new`で制御されます。 - -システムが自動的に生成するセレクターを使用していないので、新しいJobでは`manualSelector: true`を指定する必要があります。 - -``` -kind: Job -metadata: - name: new - ... -spec: - manualSelector: true - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` - -新しいJob自体は`a8f3d00d-c6d2-11e5-9f87-42010af00002`とは異なるuidを持つでしょう。 -`manualSelector: true`を設定すると、あなたが何をしているかを知っていることをシステムに伝え、この不一致を許容するようにします。 - -## 代替案 - -### ベアPod - -Podが実行されているノードが再起動したり障害が発生したりすると、Podは終了し、再起動されません。しかし、Jobは終了したPodを置き換えるために新しいPodを作成します。 -このため、アプリケーションが単一のPodしか必要としない場合でも、ベアPodではなくJobを使用することをお勧めします。 - -### レプリケーションコントローラー - -Jobは[レプリケーションコントローラー](/ja/docs/user-guide/replication-controller)を補完するものです。 -レプリケーションコントローラーは終了が予想されないPod(例えばWebサーバー)を管理し、Jobは終了が予想されるPod(例えばバッチタスク)を管理します。 - -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`または`Never`と等しいPodに対して*のみ*適切です。 -(注意: `RestartPolicy`が設定されていない場合、デフォルト値は`Always`です。) - -### 単一のJobでコントローラーPodを起動 - -もう一つのパターンは、単一のJobでPodを作成し、そのPodが他のPodを作成し、それらのPodに対するカスタムコントローラーのように動作するというものです。これは最も柔軟性がありますが、始めるのがやや複雑で、Kubernetesとの統合性が低いかもしれません。 - -このパターンの例として、Podを起動してスクリプトを実行するJobがSparkマスターコントローラー([Sparkの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)を参照)を起動し、Sparkドライバーを実行してからクリーンアップするというものがあります。 - -このアプローチの利点は、全体的なプロセスがJobオブジェクトが完了する保証を得ながらも、どのようなPodが作成され、どのように作業が割り当てられるかを完全に制御できることです。 - -## Cron Job {#cron-jobs} - -Unixのツールである`cron`と同様に、指定した日時に実行されるJobを作成するために、[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)を使用することができます。 From bf8386f235cf8dbd2499654cb8c24d13ddf90da7 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 31 Aug 2020 12:44:17 +0900 Subject: [PATCH 134/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index 1715f2cf91..d57586f905 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTLコントローラーは実行を終えたリソースオブジェクトのライフタイムを制御するためのTTL (time to live) メカニズムを提供します。 -TTLコントローラーは現在{{< glossary_tooltip text="Jobs" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 +TTLコントローラーは現在{{< glossary_tooltip text="Job" term_id="job" >}}のみ扱っていて、将来的にPodやカスタムリソースなど、他のリソースの実行終了を扱えるように拡張される予定です。 α版の免責事項: この機能は現在α版の機能で、kube-apiserverとkube-controller-managerの[Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)の`TTLAfterFinished`を有効にすることで使用可能です。 @@ -50,8 +50,7 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode ## {{% heading "whatsnext" %}} -[Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +* [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - From 6622978b23ef02e210627daf15301ba388aea3be Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 19:53:37 +0900 Subject: [PATCH 135/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../ja/docs/concepts/workloads/controllers/ttlafterfinished.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md index d57586f905..f863cb4e92 100644 --- a/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ja/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -52,5 +52,4 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode * [Jobの自動クリーンアップ](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) -[設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - +* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) From d285d43f76ab7f345d31cfee07ea333246a280de Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:44:47 +0900 Subject: [PATCH 136/303] Update kubernetes-objects.md --- .../overview/working-with-objects/kubernetes-objects.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 48cbed282a..9b3eeb7332 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -28,7 +28,7 @@ Kubernetesオブジェクトを操作するには、作成、変更、または ほとんどのKubernetesオブジェクトは、オブジェクトの設定を管理する２つの入れ子になったオブジェクトのフィールドを持っています。それはオブジェクト *`spec`* とオブジェクト *`status`* です。`spec`を持っているオブジェクトに関しては、オブジェクト作成時に`spec`を設定する必要があり、望ましい状態としてオブジェクトに持たせたい特徴を記述する必要があります。 -`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 +`status` オブジェクトはオブジェクトの *現在の状態* を示し、その情報はKubernetesシステムとそのコンポーネントにより提供、更新されます。Kubernetes{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は、あなたから指定された望ましい状態と現在の状態が一致するよう常にかつ積極的に管理をします。 例えば、KubernetesのDeploymentはクラスター上で稼働するアプリケーションを表現するオブジェクトです。Deploymentを作成するとき、アプリケーションの複製を３つ稼働させるようDeploymentのspecで指定するかもしれません。KubernetesはDeploymentのspecを読み取り、指定されたアプリケーションを３つ起動し、現在の状態がspecに一致するようにします。もしこれらのインスタンスでどれかが落ちた場合(statusが変わる)、Kubernetesはspecと、statusの違いに反応し、修正しようとします。この場合は、落ちたインスタンスの代わりのインスタンスを立ち上げます。 @@ -73,7 +73,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 * [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。 -* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)です。 +* 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。 * Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。 From e6f33dd3e624f6540a8ef8dccef77a09b5ac7481 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Fri, 11 Sep 2020 18:28:10 +0900 Subject: [PATCH 137/303] Update Japanese localization on concepts/storage/volume-pvc-datasource.md --- content/ja/docs/concepts/storage/volume-pvc-datasource.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 32e3cfb1b0..7b07e66d5b 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -31,6 +31,7 @@ weight: 30 * 複製は同じストレージクラス内でのみサポートされます。 - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。 - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。 +* 複製は同じVolumeMode設定を使用する2つのボリューム間でのみ実行できます(ブロックモードのボリュームを要求する場合、ソースもブロックモードである必要があります)。 ## プロビジョニング From f0c7c540fd531b0830fcb25158ecad063da8723e Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 14 Sep 2020 10:52:00 +0900 Subject: [PATCH 138/303] Update volume-pvc-datasource.md --- content/ja/docs/concepts/storage/volume-pvc-datasource.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/volume-pvc-datasource.md b/content/ja/docs/concepts/storage/volume-pvc-datasource.md index 7b07e66d5b..fc1b7ae4b9 100644 --- a/content/ja/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ja/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,6 @@ weight: 30 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。 From a61c14b165a97d3976f2958fd71503ffbfd8bfb4 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sun, 6 Sep 2020 15:35:39 +0900 Subject: [PATCH 139/303] finished translate --- content/ja/docs/reference/glossary/volume.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 6a81f84522..071f8b3aa6 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,17 +4,17 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - Pod内のコンテナからアクセス可能なデータを含むディレクトリです。 + データを格納するディレクトリで、Pod内のコンテナが利用可能です。 -aka: +aka: tags: - core-object - fundamental --- - {{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能なデータを含むディレクトリです。 + データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}が利用可能です。 - + -Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。 +Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。 -詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。 +詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。 From 2c2947187b41f971a72a1ea36b6df1ec582237af Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sun, 6 Sep 2020 18:17:09 +0900 Subject: [PATCH 140/303] fixed short description --- content/ja/docs/reference/glossary/volume.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index 071f8b3aa6..b9cab01761 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -4,14 +4,14 @@ id: volume date: 2018-04-12 full_link: /docs/concepts/storage/volumes/ short_description: > - データを格納するディレクトリで、Pod内のコンテナが利用可能です。 + データを格納するディレクトリで、Pod内のコンテナからアクセス可能です。 aka: tags: - core-object - fundamental --- - データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}が利用可能です。 + データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 From 8ae641909189eb0ba8477789156a389304100f30 Mon Sep 17 00:00:00 2001 From: takaf04 Date: Sun, 6 Sep 2020 20:14:42 +0900 Subject: [PATCH 141/303] Update content/ja/docs/reference/glossary/volume.md Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/volume.md b/content/ja/docs/reference/glossary/volume.md index b9cab01761..b7021ad4e4 100644 --- a/content/ja/docs/reference/glossary/volume.md +++ b/content/ja/docs/reference/glossary/volume.md @@ -11,7 +11,7 @@ tags: - core-object - fundamental --- - データを格納するディレクトリで、{{< glossary_tooltip term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 + データを格納するディレクトリで、{{< glossary_tooltip text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。 From 817e3bfe9bcedeab1f3a78ffb7fc37e4f8ae0f2f Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Mon, 14 Sep 2020 19:21:02 +0900 Subject: [PATCH 142/303] Update japanese ingress-controllers.md to follow v1.18 of the original (English) text --- .../docs/concepts/services-networking/ingress-controllers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md index f19d21ef43..f1af46c3a2 100644 --- a/content/ja/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md @@ -21,11 +21,11 @@ Ingressリソースが動作するためには、クラスターでIngressコン * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。 * [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。 -* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](http://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 +* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。 * [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。 * Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。 -* F5 Networksは[F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。 +* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。 * [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。 * [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。 * [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。 From 899e02aeb738b4dbedf486d7a0eff09398d74008 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 11 Sep 2020 12:54:22 +0900 Subject: [PATCH 143/303] Update ja/docs/tasks/administer-cluster/enabling-endpointslices.md --- .../tasks/administer-cluster/enabling-endpointslices.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index ddab0bb95d..43fc0e72ba 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -27,15 +27,13 @@ EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張 EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。 {{< /note >}} -EndpointSliceはベータ版の機能とみなされますが、デフォルトではAPIのみが有効です。kube-proxyによるEndpointSliceコントローラーとEndpointSliceの使用は、デフォルトでは有効になっていません。 +EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointを使用します、EndpointSliceではありません。 -EndpointSliceコントローラーはクラスター内にEndpointSliceを作成し、管理します。これは、{{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}と{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}の`EndpointSlice`の[フィーチャーゲート](/docs/reference/command-line-tools-reference/feature-gates/)で有効にできます(`--feature-gates=EndpointSlice=true`)。 - -スケーラビリティ向上のため、{{}}でフィーチャーゲートを有効にして、Endpointsの代わりにEndpointSliceをデータソースとして使用することもできます。 +スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 ## EndpointSliceの使用 -クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含める必要があります。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。 +クラスター内でEndpointSliceを完全に有効にすると、各Endpointsリソースに対応するEndpointSliceリソースが表示されます。既存のEndpointsの機能をサポートすることに加えて、EndpointSliceはトポロジーなどの新しい情報を含みます。これらにより、クラスター内のネットワークエンドポイントのスケーラビリティと拡張性が大きく向上します。 ## {{% heading "whatsnext" %}} From a1142f69ed44bd11005163adb10cebc1b948291e Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:15:54 +0900 Subject: [PATCH 144/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/tasks/administer-cluster/enabling-endpointslices.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index 43fc0e72ba..99b70226c9 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -27,7 +27,7 @@ EndpointSliceは、KubernetesのEndpointsに対してスケーラブルで拡張 EndpointSliceは、最終的には既存のEndpointsを置き換える可能性がありますが、多くのKubernetesコンポーネントはまだ既存のEndpointsに依存しています。現時点ではEndpointSliceを有効化することは、Endpointsの置き換えではなく、クラスター内のEndpointsへの追加とみなされる必要があります。 {{< /note >}} -EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointを使用します、EndpointSliceではありません。 +EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointSliceではなくEndpointsを使用します。 スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 @@ -41,4 +41,3 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too * [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 - From ad90db2cf50cd620eccf9e496083945bf025d811 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:16:33 +0900 Subject: [PATCH 145/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- .../docs/tasks/administer-cluster/enabling-endpointslices.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md index 99b70226c9..0718205ded 100644 --- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -29,7 +29,7 @@ EndpointSliceは、最終的には既存のEndpointsを置き換える可能性 EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_tooltip text="コントローラー" term_id="controller" >}}はデフォルトで有効です。{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}はデフォルトでEndpointSliceではなくEndpointsを使用します。 -スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetesAPI間のトラフィックの量を削減します。 +スケーラビリティと性能向上のため、kube-proxy上で`EndpointSliceProxying`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にできます。この変更はデータソースをEndpointSliceに移します、これはkube-proxyとKubernetes API間のトラフィックの量を削減します。 ## EndpointSliceの使用 @@ -40,4 +40,3 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too * [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 - From 40e06dcd41518b18710eba2924e9d0639553ec82 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 16 Sep 2020 12:19:29 +0900 Subject: [PATCH 146/303] Update ja/docs/tasks/configure-pod-container/assign-memory-resource.md --- .../assign-memory-resource.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md index 1af80012fc..944ce4b715 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -302,17 +302,17 @@ kubectl delete namespace mem-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From a27aef9dc8c67611d6631c042c0bb169932bd4ce Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 10 Sep 2020 22:44:15 +0900 Subject: [PATCH 147/303] Make docs/tasks/debug-application-cluster/_index.md follow v1.18 of the original text --- content/ja/docs/tasks/debug-application-cluster/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md index cbf41f43ff..cb2159a111 100755 --- a/content/ja/docs/tasks/debug-application-cluster/_index.md +++ b/content/ja/docs/tasks/debug-application-cluster/_index.md @@ -1,4 +1,5 @@ --- title: "監視、ログ、デバッグ" +description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とロギングをセットアップします。 weight: 80 --- From 8220b4a1c00d25824dd286979e875d65b526c490 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Mon, 14 Sep 2020 22:51:38 +0900 Subject: [PATCH 148/303] Update _index.md --- content/ja/docs/tasks/debug-application-cluster/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md index cb2159a111..bc8639bb94 100755 --- a/content/ja/docs/tasks/debug-application-cluster/_index.md +++ b/content/ja/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,5 @@ --- title: "監視、ログ、デバッグ" -description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とロギングをセットアップします。 +description: クラスターのトラブルシューティングや、コンテナ化したアプリケーションのデバッグのために、監視とログをセットアップします。 weight: 80 --- From 1c7fbc904044ce86d21ba0a08a7a64dc14187052 Mon Sep 17 00:00:00 2001 From: pururaj1908 Date: Thu, 10 Sep 2020 04:56:29 -0400 Subject: [PATCH 149/303] Updated ja minikube.md to follow v1.18 changes --- content/ja/docs/tasks/tools/install-minikube.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 30b15718ca..6b2a23d7b1 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -76,7 +76,7 @@ kubectlがインストールされていることを確認してください。 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 +Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。 このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 @@ -84,7 +84,7 @@ Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッ {{< caution >}} `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 -`--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 +`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 {{< /caution >}} MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 @@ -209,12 +209,16 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window {{< note >}} -`minikube start`で`--vm-driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 +`minikube start`で`--driver`の設定をするため、次の``の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 {{< /note >}} +{{< caution >}} +KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu：///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu：///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 +{{< /caution >}} + ```shell -minikube start --vm-driver= +minikube start --driver= ``` `minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 From e70daec5a20f465bab57e476ec7dc37997f8c0d3 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 9 Sep 2020 12:14:59 +0900 Subject: [PATCH 150/303] Update ja/docs/reference/glossary/node.md --- content/ja/docs/reference/glossary/node.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/ja/docs/reference/glossary/node.md b/content/ja/docs/reference/glossary/node.md index 0eb8976c1b..153b856243 100755 --- a/content/ja/docs/reference/glossary/node.md +++ b/content/ja/docs/reference/glossary/node.md @@ -15,3 +15,4 @@ tags: ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。 +Kubernetesの初期バージョンでは、ノードは"Minion"と呼ばれていました。 From 80c360ecfbb25173581b567ddb3566b27fd33115 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 27 Aug 2020 21:52:03 +0900 Subject: [PATCH 151/303] Update Japanese localization on concepts/workloads/pods/podpreset.md follow --- .../docs/concepts/workloads/pods/podpreset.md | 57 +++++++++---------- 1 file changed, 27 insertions(+), 30 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 42faf6bf0c..76b089fea8 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -1,30 +1,41 @@ --- reviewers: -title: Pod Preset +title: Pod Presets content_type: concept weight: 50 --- -このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 +{{< feature-state for_k8s_version="v1.6" state="alpha" >}} +このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。 ## PodPresetを理解する -`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。 -ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 +`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。 -PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。 -この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 +PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。 -PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 + +## クラスターでPodPresetを有効にする {#enable-pod-preset} + +ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 + +1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 +1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。例えば、Minikubeにおいては、クラスターの起動時に + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + を追加することで可能になります。 ## PodPresetはどのように動くか -Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。 -Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 + +Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。 1. 使用可能な全ての`PodPreset`を取得する。 1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。 @@ -32,36 +43,22 @@ Pod作成要求が発生した時、Kubernetesシステムは下記の処理を 1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。 1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-: "<リソースのバージョン>"`という形式になります。 -各Podは0以上のPodPresetにマッチすることができます。そして各`PodPreset`は0以上のPodに適用されます。単一の`PodPreset`が1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`Env`、`EnvFrom`、`VolumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`Volume`への変更があった場合、KubernetesはそのPodのSpecを修正します。 +各Podは0以上のPodPresetにマッチすることができます。そして各PodPresetは0以上のPodに適用されます。単一のPodPresetが1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`env`、`envFrom`、`volumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`volumes`への変更があった場合、KubernetesはそのPodのSpecを修正します。 {{< note >}} -単一のPodPresetは必要に応じてPodのSpec内の`.spec.containers`を修正することができます。PodPresetからのリソース定義は`initContainers`フィールドに対して1つも適用されません。 +単一のPodPresetは必要に応じてPodのspec内の以下のフィールドを修正することができます。 +- `.spec.containers`フィールド +- `.spec.initContainers`フィールド {{< /note >}} ### 特定のPodに対するPodPresetを無効にする -PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodのSpec内に次のような形式のアノテーションを追加できます。 +PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodの`.spec`内に次のような形式のアノテーションを追加できます。 `podpreset.admission.kubernetes.io/exclude: "true"` -## PodPresetを有効にする - -ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。 - -1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。 -1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。Minikubeにおいては、クラスターの起動時に - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - を追加することで可能になります。 -1. ユーザーが使う予定のNamespaceにおいて、`PodPreset`オブジェクトを作成することによりPodPresetを定義します。 - - ## {{% heading "whatsnext" %}} +[PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/) -* [PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/) - - +PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。 From 78a96c28185f1b28e5c6f382efb8ee913f2ea781 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 31 Aug 2020 09:49:54 +0900 Subject: [PATCH 152/303] Update podpreset.md --- content/ja/docs/concepts/workloads/pods/podpreset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/podpreset.md b/content/ja/docs/concepts/workloads/pods/podpreset.md index 76b089fea8..da0862be08 100644 --- a/content/ja/docs/concepts/workloads/pods/podpreset.md +++ b/content/ja/docs/concepts/workloads/pods/podpreset.md @@ -1,6 +1,6 @@ --- reviewers: -title: Pod Presets +title: Pod Preset content_type: concept weight: 50 --- From 1a1ac8f4f4151b8d6e6820294dac8841165b9f27 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 11 Sep 2020 12:21:09 +0900 Subject: [PATCH 153/303] Update ja/docs/tasks/administer-cluster/coredns.md --- content/ja/docs/tasks/administer-cluster/coredns.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 068832e852..2c6dd0bd7f 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -50,6 +50,10 @@ Kubernetesバージョン1.11以降でCoreDNSを実行している場合、ア Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。 {{< /note >}} +{{< warning >}} +Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンではは削除されます。 +{{< /warning >}} + 1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: ``` From c22eee0090265a9a1f1e6eb702a83a35142bde4c Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 11:58:31 +0900 Subject: [PATCH 154/303] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/tasks/administer-cluster/coredns.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/coredns.md b/content/ja/docs/tasks/administer-cluster/coredns.md index 2c6dd0bd7f..a2c05085f1 100644 --- a/content/ja/docs/tasks/administer-cluster/coredns.md +++ b/content/ja/docs/tasks/administer-cluster/coredns.md @@ -51,7 +51,7 @@ Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレード {{< /note >}} {{< warning >}} -Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンではは削除されます。 +Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンでは削除されます。 {{< /warning >}} 1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します: @@ -80,4 +80,3 @@ CoreDNSだけをアップグレードしたい場合や、独自のカスタム [CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。 - From 57e4e1eaabdb469b7752959b73edbc05c1a7b666 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 8 Sep 2020 12:30:40 +0900 Subject: [PATCH 155/303] Update ja/docs/reference/glossary/deployment.md --- content/ja/docs/reference/glossary/deployment.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index 569cbbd6a1..e552ab9a7a 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -4,7 +4,7 @@ id: deployment date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/deployment/ short_description: > - 複製されたアプリケーションを管理するAPIオブジェクトです。 + クラスター上の複製されたアプリケーションを管理します。 aka: tags: @@ -12,8 +12,9 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです。 + 複製されたアプリケーションを管理するAPIオブジェクトです、通常はローカル状態を持たないPodを実行します。 -各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。 +各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 +ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。 From 2d4db22652a44b0c2053251316a61f4e143d48db Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:08:10 +0900 Subject: [PATCH 156/303] update word for stateless --- content/ja/docs/reference/glossary/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index e552ab9a7a..757df66cba 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -12,7 +12,7 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです、通常はローカル状態を持たないPodを実行します。 + 複製されたアプリケーションを管理するAPIオブジェクトです、通常はステートレスなPodを実行します。 From d95d0c1f1b4d03201174204e9762948078f681aa Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Wed, 16 Sep 2020 15:05:01 +0900 Subject: [PATCH 157/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/reference/glossary/deployment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md index 757df66cba..7c9f090102 100755 --- a/content/ja/docs/reference/glossary/deployment.md +++ b/content/ja/docs/reference/glossary/deployment.md @@ -12,9 +12,9 @@ tags: - core-object - workload --- - 複製されたアプリケーションを管理するAPIオブジェクトです、通常はステートレスなPodを実行します。 + 複製されたアプリケーションを管理するAPIオブジェクトで、通常はステートレスなPodを実行します。 -各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 +各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。 ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。 From 9244f9e4aa8fe790e6fa2d30729cffb2ffd5f7b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 21 Aug 2020 15:29:14 +0900 Subject: [PATCH 158/303] translate cloud-controller.md --- .../concepts/architecture/cloud-controller.md | 140 ++++++------------ .../glossary/cloud-controller-manager.md | 18 +++ 2 files changed, 61 insertions(+), 97 deletions(-) create mode 100755 content/ja/docs/reference/glossary/cloud-controller-manager.md diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 8cf85db09b..0bff2a504e 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -1,21 +1,18 @@ --- -title: クラウドコントローラーマネージャーとそのコンセプト +title: クラウドコントローラーマネージャー content_type: concept weight: 40 --- -クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。 +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。 +クラウドインフラストラクチャ技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 -このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。 - -これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。 - -![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} +cloud-controller-managerは、プラグインメカニズムを用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 @@ -23,91 +20,49 @@ weight: 40 ## 設計 -上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します: +![Kubernetes components](/images/docs/components-of-kubernetes.png) -* Kubelet -* Kubernetesコントローラーマネージャー -* Kubernetes APIサーバー +クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 -CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります: - -![CCM Kube Arch](/images/docs/post-ccm-arch.png) - -## CCMのコンポーネント - -CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています: - - * ノードコントローラー - * ボリュームコントローラー - * ルートコントローラー - * サービスコントローラー - -バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー {{< note >}} -ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。 +コントロールプレーンの一部ではなく、Kubernetesの{{< glossary_tooltip text="addon" term_id="addons" >}}としてクラウドコントローラーマネージャーを実行することもできます。 {{< /note >}} -CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、[Flex](/docs/concepts/storage/volumes/#flexVolume)ボリュームを使うことでした。しかし、競合している[CSI](/docs/concepts/storage/volumes/#csi)として知られている機能が、Flexを置き換える予定です。 +## クラウドコントローラーマネージャーの機能 {#functions-of-the-ccm} -これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。 - -## CCMの機能群 - -CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。 - -### 1. Kubernetesコントローラーマネージャー - -CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします: - -* ノードコントローラー -* ルートコントローラー -* サービスコントローラー +クラウドコントローラーマネージャーのコントローラーは以下を含んでいます。 #### ノードコントローラー -ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します: +ノードコントローラーは、クラウドインフラストラクチャーで新しいサーバーが作成された際に、{{< glossary_tooltip text="Node" term_id="node" >}}オブジェクトを作成する責務を持ちます。ノードコントローラーは、クラウドプロバイダーのテナント内で動作しているホストの情報を取得します。ノードコントローラーは下記に示す機能を実行します: -1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する -2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する -3. ノードのネットワークアドレスとホスト名を取得する -4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する +1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する +2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする +3. ノードのホスト名とネットワークアドレスを取得する +4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する + +いくつかのクラウドプロバイダーは、これをノードコントローラーと分離ノードライフサイクルコントローラーに分けて実装しています。 #### ルートコントローラー -ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。 +ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。 + +クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。 #### サービスコントローラー -サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。 - -### 2. Kubelet - -ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。 - -この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。 - -## プラグインメカニズム - -クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化できるようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。 - -上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。 - -プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。 +{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。 ## 認可 -このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 +このセクションでは、クラウドコントローラーマネージャーが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。 -### ノードコントローラー +### ノードコントローラー {#authorization-node-controller} -ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。 +ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、readとmodifyの全権限が必要です。 -v1/Node: +`v1/Node`: - Get - List @@ -117,23 +72,23 @@ v1/Node: - Watch - Delete -### ルートコントローラー +### ルートコントローラー {#authorization-route-controller} ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。 -v1/Node: +`v1/Node`: - Get -### サービスコントローラー +### サービスコントローラー {#authorization-service-controller} -サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。 +サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのEndpointを適切に設定します。 サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。 -サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。 +サービスのEndpointリソースを設定するため、create、list、get、watchそしてupdateの権限が必要です。 -v1/Service: +`v1/Service`: - List - Get @@ -141,21 +96,21 @@ v1/Service: - Patch - Update -### その他 +### その他 {#authorization-miscellaneous} -CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 +クラウドコントローラーマネージャーのコア機能の実装は、Eventオブジェクトのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。 -v1/Event: +`v1/Event`: - Create - Patch - Update -v1/ServiceAccount: +`v1/ServiceAccount`: - Create -CCMのRBAC ClusterRoleはこのようになります: +クラウドコントローラーマネージャーの{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRoleはこのようになります: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -219,25 +174,16 @@ rules: - update ``` -## ベンダー実装 -下記のクラウドプロバイダーがCCMを実装しています: +## {{% heading "whatsnext" %}} -* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) -* [AWS](https://github.com/kubernetes/cloud-provider-aws) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) -* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) -* [Linode](https://github.com/linode/linode-cloud-controller-manager) -* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) +[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +はクラウドコントラーマネージャーの実行と管理を説明しています。 +どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -## クラスター管理 - -CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。 +クラウドコントローラーマネージェーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 +プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。 diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md new file mode 100755 index 0000000000..6e9c9104da --- /dev/null +++ b/content/ja/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: クラウドコントローラーマネージャー +id: cloud-controller-manager +date: 2018-04-12 +full_link: /ja/docs/concepts/architecture/cloud-controller/ +short_description: > + サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント +aka: +tags: +- core-object +- architecture +- operation +--- + クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。 + + + +Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。 From 26d4a99925741005207e280c1df7c3d462cbc663 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 24 Aug 2020 11:58:42 +0900 Subject: [PATCH 159/303] fix commented words --- content/ja/docs/concepts/architecture/cloud-controller.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 0bff2a504e..e3803a2a0c 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -8,7 +8,7 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドインフラストラクチャ技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 +クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} @@ -20,7 +20,7 @@ cloud-controller-managerは、プラグインメカニズムを用い、異な ## 設計 -![Kubernetes components](/images/docs/components-of-kubernetes.png) +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 From a1d78a3b866ef615513f4fc8f89884cd3a65defc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 25 Aug 2020 17:07:13 +0900 Subject: [PATCH 160/303] fix some commented words --- content/ja/docs/concepts/architecture/cloud-controller.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index e3803a2a0c..41761554ee 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -12,7 +12,7 @@ weight: 40 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} -cloud-controller-managerは、プラグインメカニズムを用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 +cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。 @@ -22,7 +22,7 @@ cloud-controller-managerは、プラグインメカニズムを用い、異な ![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) -クラウドコントローラーマネージャーは、複製されたプロセスのセットとしてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 +クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 {{< note >}} @@ -182,7 +182,7 @@ rules: どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -クラウドコントローラーマネージェーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 From 57e3ee6069f9ca71d1d1f054b1ede27a9b824588 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Thu, 17 Sep 2020 12:55:44 +0900 Subject: [PATCH 161/303] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/concepts/architecture/cloud-controller.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 41761554ee..8cdd5f21c0 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -8,7 +8,7 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーであると考えられています。 +クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。 {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} @@ -42,7 +42,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ 3. ノードのホスト名とネットワークアドレスを取得する 4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する -いくつかのクラウドプロバイダーは、これをノードコントローラーと分離ノードライフサイクルコントローラーに分けて実装しています。 +いくつかのクラウドプロバイダーは、これをノードコントローラーと個別のノードライフサイクルコントローラーに分けて実装しています。 #### ルートコントローラー From 77c4cf3dc2d330b72c54aaf31a25326da29c6afc Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Thu, 17 Sep 2020 15:53:15 +0900 Subject: [PATCH 162/303] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- content/ja/docs/concepts/architecture/cloud-controller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index 8cdd5f21c0..cf86ec011b 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -182,7 +182,7 @@ rules: どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 From ff29a34608d8840b9596ae6b2aa63b1aa0457f9d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 10 Sep 2020 19:13:57 +0900 Subject: [PATCH 163/303] translate components.md --- content/ja/docs/concepts/overview/components.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index a70f3d2e97..78d868581d 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -1,6 +1,8 @@ --- title: Kubernetesのコンポーネント content_type: concept +description: > + Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 weight: 20 card: name: concepts @@ -53,18 +55,17 @@ Kubernetesをデプロイすると、クラスターが展開されます。 ### cloud-controller-manager -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。 -cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。 +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} -cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。 +cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 +KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 -cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。 +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。 -次のコントローラーには、クラウドプロバイダーへの依存関係があります。 +次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 ## ノードコンポーネント {#node-components} From 6f905f2a581c837254fd5eeefcdcd3a6ad53763f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 20:27:29 +0900 Subject: [PATCH 164/303] apply suggestions --- "content/ja/docs/concepts/overview/\\" | 121 ++++++++++++++++++ .../ja/docs/concepts/overview/components.md | 5 +- 2 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 "content/ja/docs/concepts/overview/\\" diff --git "a/content/ja/docs/concepts/overview/\\" "b/content/ja/docs/concepts/overview/\\" new file mode 100644 index 0000000000..dbea76db1d --- /dev/null +++ "b/content/ja/docs/concepts/overview/\\" @@ -0,0 +1,121 @@ +--- +title: Kubernetesのコンポーネント +content_type: concept +description: > + Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 +weight: 20 +card: + name: concepts + weight: 20 +--- + + +Kubernetesをデプロイすると、クラスターが展開されます。 +{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} + +このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 + +すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 + +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) + + + + + +## コントロールプレーンコンポーネント + +コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 + +コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 +マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +コントローラーには以下が含まれます。 + + * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。 + * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。 + * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。 + * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。 + +### cloud-controller-manager + +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + +cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 +KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 + +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 + +次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 + + * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 + * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 + * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 +## ノードコンポーネント {#node-components} + +ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +{{< glossary_definition term_id="kube-proxy" length="all" >}} + +### コンテナランタイム {#container-runtime} + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## アドオン + +アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。 +アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。 + +いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。 + +### DNS + +クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 + +クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。 + +Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。 + + +### Web UI (ダッシュボード) + +[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 + +### コンテナリソース監視 + +[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。 + +### クラスターレベルログ + +[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。 + + +## {{% heading "whatsnext" %}} + +* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ +* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ +* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ +* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む + diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 78d868581d..dbea76db1d 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -60,14 +60,13 @@ Kubernetesをデプロイすると、クラスターが展開されます。 cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 -kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。 +kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 - + * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 ## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 From ff381e1444e2b1e437ed216e25885edc36793053 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:34:53 +0900 Subject: [PATCH 165/303] Update field-selectors.md --- .../overview/working-with-objects/field-selectors.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index ddf947212d..38415d294c 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -17,12 +17,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、下記の2つの`kubectl`クエリが同じであることを意味します。 - -```shell -kubectl get pods -kubectl get pods --field-selector "" -``` +フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、以下の2つの`kubectl`クエリ`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 {{< /note >}} ## サポートされているフィールド From a045acfe9435590f6580e0953c0de44fe73a6478 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 15 Sep 2020 23:21:41 +0900 Subject: [PATCH 166/303] apply a suggestion from review --- .../concepts/overview/working-with-objects/field-selectors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 38415d294c..78930a469a 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -17,7 +17,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、以下の2つの`kubectl`クエリ`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 +フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、`kubectl`クエリの`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。 {{< /note >}} ## サポートされているフィールド From d98ea890c20e2a04e2ca5be0d4ddce764afb0918 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 9 Sep 2020 12:45:05 +0900 Subject: [PATCH 167/303] Update ja/docs/reference/glossary/platform-developer.md --- content/ja/docs/reference/glossary/platform-developer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md index e5526cedf8..2c1452a5d9 100755 --- a/content/ja/docs/reference/glossary/platform-developer.md +++ b/content/ja/docs/reference/glossary/platform-developer.md @@ -14,4 +14,4 @@ tags: -プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 +プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-Kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 From db9eb1d2157b9569c18d88b6f08c1ae25825ed05 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:13:50 +0900 Subject: [PATCH 168/303] Apply suggestions from code review Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/glossary/platform-developer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md index 2c1452a5d9..be1e695184 100755 --- a/content/ja/docs/reference/glossary/platform-developer.md +++ b/content/ja/docs/reference/glossary/platform-developer.md @@ -14,4 +14,4 @@ tags: -プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-Kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-Kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 +プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。 From dc35c7053045dcd5326c8cb53f02535bbea1d746 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 10 Sep 2020 12:41:36 +0900 Subject: [PATCH 169/303] Update ja/docs/reference/glossary/statefulset.md --- content/ja/docs/reference/glossary/statefulset.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index 1fad77bd62..d631bb7628 100755 --- a/content/ja/docs/reference/glossary/statefulset.md +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/statefulset/ short_description: > - StatefulSetはDeploymentとPodのセットのスケーリングを管理し、それらのPodの *順序と一意性を保証* します。 + StatefulSetはDeploymentとPodのセットのスケーリングを管理します、永続化ストレージと各Podの永続的な識別子を備えています。 aka: tags: @@ -20,5 +20,4 @@ StatefulSetはDeploymentと{{< glossary_tooltip text="Pod" term_id="pod" >}}の {{< glossary_tooltip term_id="deployment" >}}のように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。 -StatefulSetは他のコントローラーと同様のパターンで動作します。ユーザーはStatefulSet*オブジェクト* の理想的な状態を定義し、StatefulSet*コントローラー* は現在の状態から、理想状態になるために必要なアップデートを行います。 - +ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。 From 594ffa7cc3dfa5148b00fc72764d9ba8213b0dff Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:12:27 +0900 Subject: [PATCH 170/303] update some words following comment --- content/ja/docs/reference/glossary/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md index d631bb7628..eb78c21fe3 100755 --- a/content/ja/docs/reference/glossary/statefulset.md +++ b/content/ja/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ja/docs/concepts/workloads/controllers/statefulset/ short_description: > - StatefulSetはDeploymentとPodのセットのスケーリングを管理します、永続化ストレージと各Podの永続的な識別子を備えています。 + StatefulSetはDeploymentとPodのセットのスケーリングを管理し、永続化ストレージと各Podの永続的な識別子を備えています。 aka: tags: From c7c7461d9468c8b30e9ed2800096072cc27eaa91 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 15 Sep 2020 12:53:27 +0900 Subject: [PATCH 171/303] Update ja/docs/tasks/configure-pod-container/assign-cpu-resource.md --- .../assign-cpu-resource.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index 8091ded576..3d0f2bb9a2 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -16,7 +16,7 @@ weight: 20 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -クラスターの各ノードには、少なくとも1つ以上のCPUが必要になります。 +タスク例を実行するには、クラスターに少なくとも利用可能な1 CPUが必要です。 このページのいくつかの手順では、クラスターにて[metrics-server](https://github.com/kubernetes-incubator/metrics-server)サービスを実行する必要があります。すでにmetrics-serverが動作している場合、これらの手順をスキップできます。 @@ -106,7 +106,7 @@ cpu-demo 974m `-cpu "2"`を設定することで、コンテナが2 CPU利用しようとすることを思い出してください。しかしながら、コンテナは約1 CPUしか使用することができません。コンテナが制限よりも多くのCPUリソースを利用しようとしているため、コンテナのCPUの利用が抑制されています。 {{< note >}} -CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、各ノードに少なくとも1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。 +CPUの使用量が1.0未満である理由の可能性して、ノードに利用可能なCPUリソースが十分にないことが挙げられます。この練習における必要条件として、クラスターに少なくとも利用可能な1 CPUが必要であることを思い出してください。1 CPUのノード上でコンテナを実行させる場合、指定したコンテナのCPU制限にかかわらず、コンテナは1 CPU以上使用することはできません。 {{< /note >}} ## CPUの単位 @@ -222,17 +222,17 @@ kubectl delete namespace cpu-example ### クラスター管理者向け -* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/memory-default-namespace/) +* [Namespaceにメモリー要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/cpu-default-namespace/) +* [NamespaceにCPU要求および制限のデフォルト値を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/memory-constraint-namespace/) +* [Namespaceに最小および最大メモリー量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) -* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/cpu-constraint-namespace/) +* [Namespaceに最小および最大のCPU使用量の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) -* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) +* [NamespaceにメモリーおよびCPUのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) -* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/quota-pod-namespace/) +* [NamespaceにPodのクォータを設定する](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) * [APIオブジェクトのクォータを設定する](/docs/tasks/administer-cluster/quota-api-object/) From 746fa8c1f7c766466a0cb0f7893f0303e581ff3a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 16 Sep 2020 15:01:29 +0900 Subject: [PATCH 172/303] delete some lines --- .../docs/tasks/configure-pod-container/assign-cpu-resource.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md index 3d0f2bb9a2..1be44e3a75 100644 --- a/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -152,9 +152,6 @@ kubectl get pod cpu-demo-2 --namespace=cpu-example この出力では、Podのステータスが待機中であることを示しています。つまり、Podがどのノードに対しても実行するようスケジュールされておらず、いつまでも待機状態のままであることを表しています: -```shell -kubectl get pod cpu-demo-2 --namespace=cpu-example -``` ``` NAME READY STATUS RESTARTS AGE cpu-demo-2 0/1 Pending 0 7m From dcc613eaf18d9e5de980a0ff45dd74f2d53aa976 Mon Sep 17 00:00:00 2001 From: daisuke0131 Date: Thu, 17 Sep 2020 00:35:16 +0900 Subject: [PATCH 173/303] Update namespaces.md --- .../overview/working-with-objects/namespaces.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index 12de8e10df..f9ebbabffd 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -33,6 +33,10 @@ Kubernetesの将来的なバージョンにおいて、同一のNamespace内の Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメント](/docs/tasks/administer-cluster/namespaces/)に記載されています。 +{{< note >}} +　　プレフィックス`kube-`を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。 +{{< /note >}} + ### Namespaceの表示 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。 @@ -41,18 +45,20 @@ Namespaceの作成と削除方法は[Namespaceの管理ガイドドキュメン kubectl get namespace ``` ``` -NAME STATUS AGE -default Active 1d -kube-system Active 1d -kube-public Active 1d +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-system Active 1d +kube-public Active 1d ``` -Kubernetesの起動時には3つの初期Namespaceが作成されています。 +Kubernetesの起動時には4つの初期Namespaceが作成されています。 * `default` 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace * `kube-system` Kubernetesシステムによって作成されたオブジェクトのためのNamespace * `kube-public` このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。) このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。 + * `kube-node-lease` クラスターのスケールに応じたノードハートビートのパフォーマンスを向上させる各ノードに関連したLeaseオブジェクトのためのNamespace。 ### Namespaceの設定 From ff8a1a5fe82768548458f99abc30c9844645ddfd Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Thu, 17 Sep 2020 19:27:10 +0900 Subject: [PATCH 174/303] modify zenkaku colon to hankaku colon --- content/ja/docs/tasks/tools/install-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/tools/install-minikube.md b/content/ja/docs/tasks/tools/install-minikube.md index 6b2a23d7b1..730145740c 100644 --- a/content/ja/docs/tasks/tools/install-minikube.md +++ b/content/ja/docs/tasks/tools/install-minikube.md @@ -214,7 +214,7 @@ WindowsにMinikubeを手動でインストールするには、[`minikube-window {{< /note >}} {{< caution >}} -KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu：///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu：///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 +KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。 {{< /caution >}} ```shell From aa8e3e5af9db762c5ffddb6212be781ad2bdb1de Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 21:40:34 +0900 Subject: [PATCH 175/303] Update container-runtimes.md --- .../container-runtimes.md | 164 +++++++++++++----- 1 file changed, 123 insertions(+), 41 deletions(-) diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 667726bc64..372523091a 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、 コンテナホストシステム上で任意のコマンドを実行する可能性があります。 -この問題の更なる情報は以下のリンクを参照してください。 -[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736) +この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。 {{< /caution >}} ### 適用性 @@ -60,34 +59,44 @@ kubeletを再起動しても問題は解決しないでしょう。 ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 +バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -# Docker CEのインストール +{{% tab name="Ubuntu 16.04+" %}} + +```shell +# (Install Docker CE) ## リポジトリをセットアップ ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` -### Docker公式のGPG鍵を追加 +```shell +# Docker公式のGPG鍵を追加: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Dockerのaptリポジトリを追加 +```shell +# Dockerのaptレポジトリを追加: add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` -## Docker CEのインストール +```shell +# Docker CEのインストール apt-get update && apt-get install -y \ - containerd.io=1.2.10-3 \ - docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) +containerd.io=1.2.13-2 \ +docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ +docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` +```shell # デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} -# Docker CEのインストール +```shell +# (Docker CEのインストール) ## リポジトリをセットアップ ### 必要なパッケージのインストール yum install -y yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### Dockerリポジトリの追加 yum-config-manager --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## Docker CEのインストール yum update -y && yum install -y \ - containerd.io-1.2.10 \ - docker-ce-19.03.4 \ - docker-ce-cli-19.03.4 + containerd.io-1.2.13 \ + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 +``` +```shell ## /etc/docker ディレクトリを作成 mkdir /etc/docker +``` +```shell # デーモンをセットアップ cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} +``` +{{% /tab %}} {{< /tabs >}} +ブート時にDockerサービスを開始させたい場合は、以下のコマンドを入力してください: + +```shell +sudo systemctl enable docker +``` + 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。 ## CRI-O @@ -179,54 +213,78 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Debian" codelang="bash" >}} +{{% tab name="Debian" %}} + +```shell # Debian Unstable/Sid echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` +```shell # Debian Testing echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - - +``` +```shell # Debian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` +```shell # Raspbian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` -# CRI-Oのインストール +それでは、CRI-Oをインストールします: +```shell sudo apt-get install cri-o-1.17 -{{< /tab >}} +``` +{{% /tab %}} -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} -# リポジトリの設定 +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + +```shell +# パッケージレポジトリを設定する . /etc/os-release sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - sudo apt-get update +``` +```shell # CRI-Oのインストール sudo apt-get install cri-o-1.17 -{{< /tab >}} +``` +{{% /tab %}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell # 必要なパッケージのインストール -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` +```shell # CRI-Oのインストール -yum install --nogpgcheck -y cri-o -{{< /tab >}} +yum install -y cri-o +``` +{{% /tab %}} -{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +{{% tab name="openSUSE Tumbleweed" %}} + +```shell sudo zypper install cri-o -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} ### CRI-Oの起動 -``` +```shell systemctl daemon-reload systemctl start crio ``` @@ -264,51 +322,75 @@ sysctl --system {{< tabs name="tab-cri-containerd-installation" >}} {{< tab name="Ubuntu 16.04" codelang="bash" >}} -# containerdのインストール + +```shell +# (containerdのインストール) ## リポジトリの設定 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` -### Docker公式のGPG鍵を追加 +```shell +## Docker公式のGPG鍵を追加 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Dockerのaptリポジトリの追加 +``` +## Dockerのaptリポジトリの追加 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## containerdのインストール apt-get update && apt-get install -y containerd.io +``` +```shell # containerdの設定 mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # containerdの再起動 systemctl restart containerd -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# containerdのインストール +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell +# (containerdのインストール) ## リポジトリの設定 ### 必要なパッケージのインストール yum install -y yum-utils device-mapper-persistent-data lvm2 +``` -### Dockerのリポジトリの追加 +```shell +## Dockerのリポジトリの追加 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## containerdのインストール yum update -y && yum install -y containerd.io +``` -# containerdの設定 +```shell +## containerdの設定 mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # containerdの再起動 systemctl restart containerd -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} ### systemd From 5753e47564d08d5059b435d96b35390d0cf29260 Mon Sep 17 00:00:00 2001 From: inductor Date: Mon, 14 Sep 2020 13:54:03 +0900 Subject: [PATCH 176/303] update feature gaet --- .../feature-gates.md | 95 +++++++++++++------ 1 file changed, 67 insertions(+), 28 deletions(-) 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 4c2da51da6..28fc42d0ca 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 @@ -35,23 +35,18 @@ content_type: concept | 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン | |---------|---------|-------|-------|-------| +| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | | | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | | | `AppArmor` | `true` | Beta | 1.4 | | | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | -| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | -| `BlockVolume` | `true` | Beta | 1.13 | - | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 | | `CRIContainerLogRotation` | `true` | Beta| 1.11 | | -| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 | -| `CSIBlockVolume` | `true` | Beta | 1.14 | | -| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | -| `CSIDriverRegistry` | `true` | Beta | 1.14 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | Beta | 1.16 | - | | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 | @@ -68,6 +63,7 @@ content_type: concept | `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | | | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | | +| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 | | `CustomResourceDefaulting` | `true` | Beta | 1.16 | | @@ -80,6 +76,8 @@ content_type: concept | `DynamicKubeletConfig` | `true` | Beta | 1.11 | | | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 | | `EndpointSlice` | `false` | Beta | 1.17 | | +| `EndpointSlice` | `true` | Beta | 1.18 | | +| `EndpointSliceProxying` | `false` | Alpha | 1.18 | | | `EphemeralContainers` | `false` | Alpha | 1.16 | | | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 | | `ExpandCSIVolumes` | `true` | Beta | 1.16 | | @@ -88,9 +86,12 @@ content_type: concept | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | | -| `EvenPodsSpread` | `false` | Alpha | 1.16 | | +| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 | +| `EvenPodsSpread` | `true` | Beta | 1.18 | | | `HPAScaleToZero` | `false` | Alpha | 1.16 | | +| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | | | `HyperVContainer` | `false` | Alpha | 1.10 | | +| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | | | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | | @@ -100,6 +101,8 @@ content_type: concept | `MountContainers` | `false` | Alpha | 1.9 | | | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | | +| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | Beta | 1.5 | | | `PodOverhead` | `false` | Alpha | 1.16 | - | | `ProcMountType` | `false` | Alpha | 1.12 | | | `QOSReserved` | `false` | Alpha | 1.11 | | @@ -114,8 +117,12 @@ content_type: concept | `SCTPSupport` | `false` | Alpha | 1.12 | | | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | | `ServerSideApply` | `true` | Beta | 1.16 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | | -| `StartupProbe` | `true` | Beta | 1.17 | | +| `ServiceTopology` | `false` | Alpha | 1.17 | | +| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 | +| `StartupProbe` | `true` | Beta | 1.18 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | @@ -125,8 +132,6 @@ content_type: concept | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 | | `SupportPodPidsLimit` | `true` | Beta | 1.14 | | | `Sysctls` | `true` | Beta | 1.11 | | -| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 | -| `TaintBasedEvictions` | `true` | Beta | 1.13 | | | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 | | `TokenRequest` | `true` | Beta | 1.12 | | | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | @@ -160,6 +165,15 @@ content_type: concept | `AffinityInAnnotations` | - | Deprecated | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | +| `BlockVolume` | `true` | Beta | 1.13 | 1.17 | +| `BlockVolume` | `true` | GA | 1.18 | - | +| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 | +| `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 | +| `CSIBlockVolume` | `true` | GA | 1.18 | - | +| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | +| `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 | +| `CSIDriverRegistry` | `true` | GA | 1.18 | | | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 | | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 | | `CSINodeInfo` | `true` | GA | 1.17 | | @@ -240,9 +254,18 @@ content_type: concept | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 | | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - | +| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 | +| `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 | +| `TaintBasedEvictions` | `true` | GA | 1.18 | - | | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 | | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 | | `TaintNodesByCondition` | `true` | GA | 1.17 | - | +| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 | +| `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 | +| `VolumePVCDataSource` | `true` | GA | 1.18 | - | +| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | +| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | +| `VolumeScheduling` | `true` | GA | 1.13 | - | | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | | `VolumeScheduling` | `true` | GA | 1.13 | - | @@ -253,6 +276,12 @@ content_type: concept | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 | | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 | | `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 | +| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 | +| `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 | +| `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 | +| `WindowsRunAsUserName` | `true` | GA | 1.18 | - | {{< /table >}} ## 機能を使用する @@ -292,7 +321,8 @@ GAになってからさらなる変更を加えることは現実的ではない - `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。 - `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。 -- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。 +- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を有効にします。 +- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}の`DataSource`としてカスタムリソースの使用を有効にします。 - `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。 `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。 @@ -302,6 +332,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。 - `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。 +- `ConfigurableFSGroupPolicy`: Podにボリュームをマウントするときに、ユーザーがfsGroupsのボリューム権限変更ポリシーを設定できるようにします。詳細については、[Podのボリューム権限と所有権変更ポリシーの設定](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をご覧ください。 - `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。 - `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。 - `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。 @@ -309,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 -- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。 CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 +- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングしますCSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 @@ -325,9 +356,9 @@ GAになってからさらなる変更を加えることは現実的ではない - `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/ja/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。 - `CustomResourceDefaulting`: OpenAPI v3バリデーションスキーマにおいて、デフォルト値のCRDサポートを有効にします。 - `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。 -- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 -- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 -- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。 +- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。 +- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。 +- `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)を有効にします。 @@ -340,29 +371,33 @@ GAになってからさらなる変更を加えることは現実的ではない - `EvenPodsSpread`: Podをトポロジードメイン全体で均等にスケジュールできるようにします。[Even Pods Spread](/docs/concepts/configuration/even-pods-spread)をご覧ください。 - `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。 - `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。 -- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。 +- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のPodへの *クリティカル* の注釈を加える設定を有効にします。 - `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。 -- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。対応するAPIとコントローラーを有効にする必要があります。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 +- `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。 +- `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。 - `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。 +- `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。 +- `ImmutableEphemeralVolumes`: 安全性とパフォーマンスを向上させるために、個々のSecretとConfigMapが不変となるように指定できるようにします。 - `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。 - `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。 -- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。 +- `KubeletPodResources`: kubeletのPodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)で確認できます。 - `LegacyNodeRoleBehavior`: 無効にすると、サービスロードバランサーの従来の動作とノードの中断により機能固有のラベルが優先され、`node-role.kubernetes.io/master`ラベルが無視されます。 -- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 -- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 +- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。 +- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。 - `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。 -- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 +- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはPodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。 - `NodeDisruptionExclusion`: ノードラベル`node.kubernetes.io/exclude-disruption`の使用を有効にします。これにより、ゾーン障害時にノードが退避するのを防ぎます。 - `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。 - `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。 -- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。 +- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、Podアフィニティを指定する必要があります。 - `PodOverhead`: [PodOverhead](/docs/concepts/configuration/pod-overhead/)機能を有効にして、Podのオーバーヘッドを考慮するようにします。 +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 -- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。 詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 +- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。 @@ -375,26 +410,30 @@ GAになってからさらなる変更を加えることは現実的ではない - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。 - `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。 +- `ServiceAccountIssuerDiscovery`: APIサーバーにてサービスアカウント発行者のOIDC検出エンドポイント（発行者とJWKS URL）を有効にします。詳細については、[Podのサービスアカウント設定](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)をご覧ください。 +- `ServiceAppProtocol`: サービスとエンドポイントで`AppProtocol`フィールドを有効にします。 - `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。 - `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーまたは`node.kubernetes.io/exclude-from-external-load-balancers`でラベル付けされている場合ノードは除外の対象となります。 +- `ServiceTopology`: クラスタのノードトポロジーに基づいてトラフィックをルーティングするサービスを有効にします。詳細については、[Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology/)を参照してください。 - `StartupProbe`: kubeletで[startup](/ja/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)プローブを有効にします。 - `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。 - `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。 - `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。 - `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシー](/ja/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。 - `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。 -- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。 -- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。 -- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。 +- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。 +- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。 +- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。 -- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。 +- `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。 - `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。 - `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。 - `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。 -- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。 +- `WindowsGMSA`: GMSA資格仕様をPodからコンテナランタイムに渡せるようにします。 +- `WindowsRunAsUserName`: デフォルト以外のユーザーでWindowsコンテナアプリケーションを実行するためのサポートを有効にします。詳細については、[RunAsUserNameの設定](/docs/tasks/configure-pod-container/configure-runasusername)を参照してください。 - `WinDSR`: kube-proxyがWindows用のDSRロードバランサーを作成できるようにします。 - `WinOverlay`: kube-proxyをWindowsのオーバーレイモードで実行できるようにします。 From 2f2ebae42766c33135a5ebcafe24f20b1f525946 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Tue, 15 Sep 2020 01:55:35 +0900 Subject: [PATCH 177/303] Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md --- .../reference/command-line-tools-reference/feature-gates.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) 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 28fc42d0ca..e01de4d5f9 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 @@ -397,7 +397,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。 -- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 +- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。 @@ -441,4 +441,3 @@ GAになってからさらなる変更を加えることは現実的ではない ## {{% heading "whatsnext" %}} * Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。 - From c2658dfc74f3282d778d0442fa515858e566e4a4 Mon Sep 17 00:00:00 2001 From: "inductor(Kohei)" Date: Tue, 15 Sep 2020 01:56:39 +0900 Subject: [PATCH 178/303] Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md --- .../reference/command-line-tools-reference/feature-gates.md | 2 +- 1 file changed, 1 insertion(+), 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 e01de4d5f9..819f269611 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 @@ -340,7 +340,7 @@ GAになってからさらなる変更を加えることは現実的ではない - `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。 - `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。 - `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。ノードにEBS CSIプラグインがインストールおよび設定されていない場合、ツリー内のEBSプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 -- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングしますCSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 +- `CSIMigrationAWSComplete`: EBSツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、AWS-EBSツリー内プラグインからEBS CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAWS機能フラグを有効にし、クラスター内のすべてのノードにEBS CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。ノードにAzureDisk CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureDiskプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 - `CSIMigrationAzureDiskComplete`: Azure-Diskツリー内プラグインのkubeletおよびボリュームコントローラーへの登録を停止し、シムと変換ロジックを有効にして、Azure-Diskツリー内プラグインからAzureDisk CSIプラグインにボリューム操作をルーティングします。CSIMigrationおよびCSIMigrationAzureDisk機能フラグを有効にし、クラスター内のすべてのノードにAzureDisk CSIプラグインをインストールおよび設定する必要があります。 - `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。ノードにAzureFile CSIプラグインがインストールおよび設定されていない場合、ツリー内のAzureFileプラグインへのフォールバックをサポートします。CSIMigration機能フラグを有効にする必要があります。 From 06213569774e83d9a82d866f232d963ff417fbab Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 17 Sep 2020 12:49:38 +0900 Subject: [PATCH 179/303] Update ja/docs/concepts/workloads/controllers/cron-jobs.md --- .../workloads/controllers/cron-jobs.md | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 60e8e68370..5351fe8133 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -8,7 +8,7 @@ weight: 80 {{< feature-state for_k8s_version="v1.8" state="beta" >}} -_CronJob_ は時刻ベースのスケジュールによって[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)を作成します。 +_CronJob_ は繰り返しのスケジュールによって{{< glossary_tooltip term_id="job" text="Job" >}}を作成します。 _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみられる一行のようなものです。 [Cron](https://ja.wikipedia.org/wiki/Cron)形式で記述された指定のスケジュールの基づき、定期的にジョブが実行されます。 @@ -22,13 +22,25 @@ _CronJob_ オブジェクトとは _crontab_ (cron table)ファイルでみら CronJobリソースのためのマニフェストを作成する場合、その名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)か確認してください。 名前は52文字を超えることはできません。これはCronJobコントローラーが自動的に、与えられたジョブ名に11文字を追加し、ジョブ名の長さは最大で63文字以内という制約があるためです。 -cronジョブを作成し、実行するインストラクション、または、cronジョブ仕様ファイルのサンプルについては、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)をご覧ください。 -## CronJobの制限 +## CronJob + +CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするような特定時における個々のタスクをスケジュールすることもできます。 + +### 例 + +このCronJobマニフェスト例は、毎分ごとに現在の時刻とhelloメッセージを表示します。 + +{{< codenew file="application/job/cronjob.yaml" >}} + +([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。). + +## CronJobの制限 {#cron-job-limitations} cronジョブは一度のスケジュール実行につき、 _おおよそ_ 1つのジョブオブジェクトを作成します。ここで _おおよそ_ と言っているのは、ある状況下では2つのジョブが作成される、もしくは1つも作成されない場合があるためです。通常、このようなことが起こらないようになっていますが、完全に防ぐことはできません。したがって、ジョブは _冪等_ であるべきです。 @@ -50,4 +62,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). CronJobはスケジュールに一致するJobの作成にのみ関与するのに対して、JobはJobが示すPod管理を担います。 +## {{% heading "whatsnext" %}} +[Cron表現形式](https://en.wikipedia.org/wiki/Cron)では、CronJobの`schedule`フィールドのフォーマットを説明しています。 + +cronジョブの作成や動作の説明、CronJobマニフェストの例については、[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs)を見てください。 From 3c8bd09da5064a5c4dc3b1ebd699a1765972342b Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 18 Sep 2020 11:47:29 +0900 Subject: [PATCH 180/303] Apply suggestions from code review Co-authored-by: bells17 --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 5351fe8133..20c465c3a7 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -30,7 +30,7 @@ CronJobリソースのためのマニフェストを作成する場合、その ## CronJob CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 -CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするような特定時における個々のタスクをスケジュールすることもできます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするようなど、特定の時間に個々のタスクをスケジュールすることもできます。 ### 例 From 5b6c6a8e65c26e0e3944204a14f2aaebc4b70783 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 11:56:28 +0900 Subject: [PATCH 181/303] fix some word --- content/ja/docs/concepts/workloads/controllers/cron-jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 20c465c3a7..5f820a187a 100644 --- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md @@ -30,7 +30,7 @@ CronJobリソースのためのマニフェストを作成する場合、その ## CronJob CronJobは、バックアップの実行やメール送信のような定期的であったり頻発するタスクの作成に役立ちます。 -CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするようなど、特定の時間に個々のタスクをスケジュールすることもできます。 +CronJobは、クラスターがアイドル状態になりそうなときにJobをスケジューリングするなど、特定の時間に個々のタスクをスケジュールすることもできます。 ### 例 From 8fbf98518ca83eb4eeff5c4a920e79f3ce69e844 Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Thu, 10 Sep 2020 18:05:03 +0900 Subject: [PATCH 182/303] =?UTF-8?q?issue-23614=E3=81=AE=E6=97=A5=E6=9C=AC?= =?UTF-8?q?=E8=AA=9E=E7=BF=BB=E8=A8=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../docs/concepts/overview/kubernetes-api.md | 119 +++++++++++------- 1 file changed, 72 insertions(+), 47 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 5d95929bef..764fae9d0b 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -3,6 +3,9 @@ reviewers: title: Kubernetes API content_type: concept weight: 30 +description: > + Kubernetes APIを使用すると、Kubernetes内のオブジェクトの状態をクエリで操作できます。 + Kubernetesのコントロールプレーンの中核は、APIサーバーとそれが公開するHTTP APIです。ユーザー、クラスターのさまざまな部分、および外部コンポーネントはすべて、APIサーバーを介して互いに通信します。 card: name: concepts weight: 30 @@ -10,64 +13,78 @@ card: -全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。 - -APIエンドポイント、リソースタイプ、そしてサンプルは[APIリファレンス](/docs/reference)に記載されています。 - -APIへの外部からのアクセスは、[APIアクセス制御ドキュメント](/docs/reference/access-authn-authz/controlling-access/)に記載されています。 - -Kubernetes APIは、システムの宣言的設定スキーマの基礎としても機能します。[kubectl](/docs/reference/kubectl/overview/)コマンドラインツールから、APIオブジェクトを作成、更新、削除、取得することができます。 - -また、Kubernetesは、シリアライズされた状態を(現在は[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)に)APIリソースの単位で保存しています。 - -Kubernetesそれ自身は複数のコンポーネントから構成されており、APIを介して連携しています。 +Kubernetesの中核である' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 +APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。 +Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 +APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。 ## APIの変更 -我々の経験上、成功を収めているどのようなシステムも、新しいユースケースへの対応、既存の変更に合わせ、成長し変わっていく必要があります。したがって、Kubernetesにも継続的に変化、成長することを期待しています。一方で、長期間にわたり、既存のクライアントとの互換性を損なわないようにする予定です。一般的に、新しいAPIリソースとリソースフィールドは頻繁に追加されることが予想されます。リソース、フィールドの削除は、[API廃止ポリシー](/docs/reference/using-api/deprecation-policy/)への準拠を必要とします。 +成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。 +したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。 +Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 -何が互換性のある変更を意味するか、またAPIをどのように変更するかは、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)に詳解されています。 +基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 +リソースまたはフィールドを削除するには、次のポリシーに従ってください。[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/). -## OpenAPIとSwaggerの定義 +互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 -完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)に記載されています。 -Kubernetes 1.10から、KubernetesAPIサーバーは`/openapi/v2`のエンドポイントを通じて、OpenAPI仕様を提供しています。 -リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます: +**OpenAPI 仕様 {#api-specification} -ヘッダ | 設定可能な値 ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません) -Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています) +Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 +次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 -1.14より前のバージョンでは、フォーマット分離エンドポイント(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)が、OpenAPI仕様を違うフォーマットで提供しています。これらのエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 -**OpenAPI仕様の取得サンプル**: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HeaderPossible valuesNotes
Accept-Encodinggzipこのヘッダーを使わないことも可能
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobuf主にクラスター内での使用
application/jsonデフォルト
*application/jsonを提供
OpenAPI v2クエリの有効なリクエストヘッダー値
-1.10より前 | Kubernetes1.10以降 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 -また、1.14より前のバージョンのKubernetesAPIサーバーでは、[Swagger v1.2](http://swagger.io/)をベースにしたKubernetes仕様を、`/swaggerapi`で公開しています。 -このエンドポイントは非推奨となっており、Kubernetes1.14で削除されました。 - ## APIバージョニング -フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/extensions/v1beta1`のように、それぞれ異なるAPIのパスが割り当てられています。 +フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。 -APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンを付けることを選択しました。JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 +APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。 + +JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 -異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: +異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: - アルファレベル(版): - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 @@ -88,29 +105,37 @@ APIとソフトウエアのバージョニングは、間接的にしか関連 ## APIグループ {#api-groups} -KubernetesAPIの拡張を簡易に行えるようにするため、[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 +APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。 -現在、いくつかのAPIグループが利用されています: +クラスターにはいくつかのAPIグループがあります: -1. *core* グループ(たびたび、*legacy group* と呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 +1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 -1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。サポートされているAPIグループの全リストは、[Kubernetes APIリファレンス](/docs/reference/)を参照してください。 +1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。 -[カスタムリソース](/docs/concepts/api-extension/custom-resources/)でAPIを拡張するために、2つの方法がサポートされています: +[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります: -1. [カスタムリソース定義](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)は、とても基本的なCRUDが必要なユーザー向けです。 -1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。 +1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。 +1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。 ## APIグループの有効化、無効化 -いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、APIサーバーの`--runtime-config`設定で、有効化、無効化できます。`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 +いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。 -{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、APIサーバーとコントローラーマネージャーの再起動が必要です。{{< /note >}} +`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 -## APIグループextensions/v1beta1に含まれる特定のリソースの有効化 +{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}} -APIグループ`extensions/v1beta1`に含まれるDaemonSets、Deployments、StatefulSet、NetworkPolicies、PodSecurityPolicies、ReplicaSetsはデフォルトで無効にされています。 -例えば、deploymentとdaemonsetを有効にするには、`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`と設定します。 +## 永続性 -{{< note >}}リソースを個別に有効化、無効化することは歴史的な理由によりAPIグループ`extensions/v1beta1`に含まれるリソースに限りサポートされています。{{< /note >}} +KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。 + + +## {{% heading "whatsnext" %}} + +[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 + +全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。 + +APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。 From 8f0e8074b6cb50953b38084b19ae110801fb18d9 Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Sat, 12 Sep 2020 09:44:57 +0900 Subject: [PATCH 183/303] =?UTF-8?q?issue-23614=E3=81=AE=E6=97=A5=E6=9C=AC?= =?UTF-8?q?=E8=AA=9E=E7=BF=BB=E8=A8=B3=20=E3=82=B3=E3=83=A1=E3=83=B3?= =?UTF-8?q?=E3=83=88=E5=AF=BE=E5=BF=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/overview/kubernetes-api.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 764fae9d0b..188d463df8 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -13,7 +13,7 @@ card: -Kubernetesの中核である' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 +Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。 APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。 Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 @@ -34,7 +34,7 @@ Kubernetesプロジェクトは、既存のクライアントとの互換性を 互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 -**OpenAPI 仕様 {#api-specification} +## OpenAPI 仕様 {#api-specification} Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 From fd3dcc27774b02fcd2b20728b22861d3fda3561f Mon Sep 17 00:00:00 2001 From: yoichiro0217 Date: Fri, 18 Sep 2020 17:55:43 +0900 Subject: [PATCH 184/303] =?UTF-8?q?=E3=82=B3=E3=83=A1=E3=83=B3=E3=83=88?= =?UTF-8?q?=E5=AF=BE=E5=BF=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/overview/kubernetes-api.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 188d463df8..251f671b6d 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -29,13 +29,15 @@ APIエンドポイント、リソースタイプ、サンプルについては[A Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 -リソースまたはフィールドを削除するには、次のポリシーに従ってください。[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/). +リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。 -互換性のある変更の構成要素とAPIの変更方法については、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 +互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 ## OpenAPI 仕様 {#api-specification} +完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。 + Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。 次のように要求ヘッダーを使用して、応答フォーマットを要求できます。 @@ -84,7 +86,7 @@ JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更 APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 -異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[API変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: +異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: - アルファレベル(版): - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 From 088c4dc011ee9e9c4ce5b1b974b98049f86d7f71 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 12:15:36 +0900 Subject: [PATCH 185/303] Update ja/docs/concepts/services-networking/connect-applications-service.md --- .../services-networking/connect-applications-service.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md index 0d61ce938c..423b114096 100644 --- a/content/ja/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md @@ -23,7 +23,6 @@ Kubernetesでは、どのホストで稼働するかに関わらず、Podが他 このドキュメントの残りの部分では、このようなネットワークモデルで信頼できるサービスを実行する方法について詳しく説明します。 このガイドでは、シンプルなnginxサーバーを使用して概念実証を示します。 -同じ原則が、より完全な[Jenkins CIアプリケーション](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)で具体化されています。 @@ -140,7 +139,7 @@ Service IPは完全に仮想的なもので、ホスト側のネットワーク ## Serviceにアクセスする Kubernetesは、環境変数とDNSの2つの主要なService検索モードをサポートしています。 -前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。 +前者はそのまま使用でき、後者は[CoreDNSクラスタアドオン](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)を必要とします。 {{< note >}} サービス環境変数が望ましくない場合(予想されるプログラム変数と衝突する可能性がある、処理する変数が多すぎる、DNSのみを使用するなど)、[Pod仕様](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)で`enableServiceLinks`フラグを`false`に設定することでこのモードを無効にできます。 {{< /note >}} @@ -400,8 +399,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https:// -k From 7a6f50df4dc1f320d8d72b45b71956202d692615 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 18 Sep 2020 13:21:39 +0900 Subject: [PATCH 186/303] Update ja/docs/concepts/services-networking/dns-pod-service.md --- .../services-networking/dns-pod-service.md | 20 ++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index 7e65022304..4375928a45 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -42,6 +42,20 @@ Headless Serviceに対しては、このSRVレコードは複数の結果を返 ## Pod +### A/AAAAレコード + +一般的にPodは下記のDNS解決となります。 + +`pod-ip-address.my-namespace.pod.cluster-domain.example` + +例えば、`default`ネームスペースのpodのIPアドレスが172.17.0.3で、クラスターのドメイン名が`cluster.local`の場合、PodのDNS名は以下になります。 + +`172-17-0-3.default.pod.cluster.local` + +DeploymentかDaemonSetに作成され、Serviceに公開されるどのPodも以下のDNS解決が利用できます。 + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example` + ### Podのhostnameとsubdomainフィールド 現在、Podが作成されたとき、そのPodのホスト名はPodの`metadata.name`フィールドの値となります。 @@ -113,9 +127,9 @@ A(AAAA)レコードはPodの名前に対して作成されないため、`hostna DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。 - "`Default`": そのPodはPodが稼働しているNodeから名前解決の設定を継承します。詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)を参照してください。 -- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。 +- "`ClusterFirst`": "`www.kubernetes.io`"のようなクラスタードメインのサフィックスにマッチしないようなDNSクエリーは、Nodeから継承された上流のネームサーバーにフォワーディングされます。クラスター管理者は、追加のstubドメインと上流のDNSサーバーを設定できます。このような場合におけるDNSクエリー処理の詳細に関しては、[関連する議論](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)を参照してください。 - "`ClusterFirstWithHostNet`": hostNetworkによって稼働しているPodに対しては、ユーザーは明示的にDNSポリシーを"`ClusterFirstWithHostNet`"とセットするべきです。 -- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-s-dns-config)を参照ください。 +- "`None`": この設定では、Kubernetesの環境からDNS設定を無視することができます。全てのDNS設定は、Pod Spec内の`dnsConfig`フィールドを指定して提供することになっています。下記のセクションの[Pod's DNS config](#pod-dns-config)を参照ください。 {{< note >}} "Default"は、デフォルトのDNSポリシーではありません。もし`dnsPolicy`が明示的に指定されていない場合、"ClusterFirst"が使用されます。 @@ -142,7 +156,7 @@ spec: dnsPolicy: ClusterFirstWithHostNet ``` -### PodのDNS設定 {#pods-dns-config} +### PodのDNS設定 {#pod-dns-config} PodのDNS設定は、ユーザーがPodに対してそのDNS設定上でさらに制御するための手段を提供します。 From 890c2121010383705bd0c0ea096ac7a9d203ea63 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sun, 13 Sep 2020 22:00:59 +0900 Subject: [PATCH 187/303] Translated multiple-zones.md --- .../setup/best-practices/multiple-zones.md | 163 ++++++------------ 1 file changed, 55 insertions(+), 108 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 3590f6fa8c..41b24cb29f 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -14,93 +14,50 @@ This page describes how to run a cluster in multiple zones. ## 始めに -Kubernetes 1.2 adds support for running a single cluster in multiple failure zones -(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones"). -This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate -nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)). -Full Cluster Federation allows combining separate -Kubernetes clusters running in different regions or cloud providers -(or on-premises data centers). However, many -users simply want to run a more available Kubernetes cluster in multiple zones -of their single cloud provider, and this is what the multizone support in 1.2 allows -(this previously went by the nickname "Ubernetes Lite"). +Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 +これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 +完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に１つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 -Multizone support is deliberately limited: a single Kubernetes cluster can run -in multiple zones, but only within the same region (and cloud provider). Only -GCE and AWS are currently supported automatically (though it is easy to -add similar support for other clouds or even bare metal, by simply arranging -for the appropriate labels to be added to nodes and volumes). +マルチゾーンサポートは故意に限定されています: １つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 ## 機能性 -When nodes are started, the kubelet automatically adds labels to them with -zone information. +ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。 -Kubernetes will automatically spread the pods in a replication controller -or service across nodes in a single-zone cluster (to reduce the impact of -failures.) With multiple-zone clusters, this spreading behavior is -extended across zones (to reduce the impact of zone failures.) (This is -achieved via `SelectorSpreadPriority`). This is a best-effort -placement, and so if the zones in your cluster are heterogeneous -(e.g. different numbers of nodes, different types of nodes, or -different pod resource requirements), this might prevent perfectly -even spreading of your pods across zones. If desired, you can use -homogeneous zones (same number and types of nodes) to reduce the -probability of unequal spreading. +Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード，異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。 -When persistent volumes are created, the `PersistentVolumeLabel` -admission controller automatically adds zone labels to them. The scheduler (via the -`VolumeZonePredicate` predicate) will then ensure that pods that claim a -given volume are only placed into the same zone as that volume, as volumes -cannot be attached across zones. +永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。 ## 制限 -There are some important limitations of the multizone support: +マルチゾーンサポートにはいくつか重要な制限があります: -* We assume that the different zones are located close to each other in the -network, so we don't perform any zone-aware routing. In particular, traffic -that goes via services might cross zones (even if some pods backing that service -exist in the same zone as the client), and this may incur additional latency and cost. +* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。 -* Volume zone-affinity will only work with a `PersistentVolume`, and will not -work if you directly specify an EBS volume in the pod spec (for example). +* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。 -* Clusters cannot span clouds or regions (this functionality will require full -federation support). +* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。 -* Although your nodes are in multiple zones, kube-up currently builds -a single master node by default. While services are highly -available and can tolerate the loss of a zone, the control plane is -located in a single zone. Users that want a highly available control -plane should follow the [high availability](/docs/admin/high-availability) instructions. +*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに位置します。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 ### ボリュームの制限 -The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). -* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with - pod affinity or anti-affinity policies. +以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。 -* If the name of the StatefulSet contains dashes ("-"), volume zone spreading - may not provide a uniform distribution of storage across zones. +* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。 -* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass - needs to be configured for a specific single zone, or the PVs need to be - statically provisioned in a specific zone. Another workaround is to use a - StatefulSet, which will ensure that all the volumes for a replica are - provisioned in the same zone. +* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供ない可能性があります。 + +* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 ## 全体の流れ -We're now going to walk through setting up and using a multi-zone -cluster on both GCE & AWS. To do so, you bring up a full cluster -(specifying `MULTIZONE=true`), and then you add nodes in additional zones -by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`). +GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。 ### クラスターの立ち上げ -Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a. +通常と同様にクラスターを作成します、しかし複数のゾーンを管理するためにMULTIZONEをクラスターに設定します。ノードをus-central1-aに作成します。 GCE: @@ -114,21 +71,20 @@ AWS: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash ``` -This step brings up a cluster as normal, still running in a single zone -(but `MULTIZONE=true` has enabled multi-zone capabilities). +このステップは通常と同様にクラスターを立ち上げ、１つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 + ### ノードはラベルが付与される -View the nodes; you can see that they are labeled with zone information. -They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The -labels are `failure-domain.beta.kubernetes.io/region` for the region, -and `failure-domain.beta.kubernetes.io/zone` for the zone: +ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。 +それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`failure-domain.beta.kubernetes.io/region`がリージョンに、`failure-domain.beta.kubernetes.io/zone`はゾーンに付けられています: + ```shell kubectl get nodes --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME STATUS ROLES AGE VERSION LABELS @@ -140,11 +96,8 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -Let's add another set of nodes to the existing cluster, reusing the -existing master, running in a different zone (us-central1-b or us-west-2b). -We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true` -kube-up will not create a new master, but will reuse one that was previously -created instead. +それでは、現存のマスターを再利用して現存のクラスターにもう１つのノードのセットを追加しましょう。 +kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -152,22 +105,21 @@ GCE: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh ``` -On AWS we also need to specify the network CIDR for the additional -subnet, along with the master internal IP address: + +AWSではマスターの内部IPアドレスに加えて追加のサブネット用のネットワークCIDRを指定する必要があります: ```shell KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -View the nodes again; 3 more nodes should have launched and be tagged -in us-central1-b: +ノードをもう１度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: ```shell kubectl get nodes --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME STATUS ROLES AGE VERSION LABELS @@ -182,7 +134,7 @@ kubernetes-minion-wf8i Ready 2m v1.13.0 ### ボリュームのアフィニティ -Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity): +動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています): ```bash kubectl apply -f - <}} -For version 1.3+ Kubernetes will distribute dynamic PV claims across -the configured zones. For version 1.2, dynamic persistent volumes were -always created in the zone of the cluster master -(here us-central1-a / us-west-2a); that issue +バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。 +バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。 +(ここではus-central1-a / us-west-2a); このイシューは ([#23330](https://github.com/kubernetes/kubernetes/issues/23330)) -was addressed in 1.3+. +にバージョン1.3以降で記載されています。 {{< /note >}} -Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. +それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。 ```shell kubectl get pv --show-labels ``` -The output is similar to this: +結果は以下のようになります: ```shell NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` -So now we will create a pod that uses the persistent volume claim. -Because GCE PDs / AWS EBS volumes cannot be attached across zones, -this means that this pod can only be created in the same zone as the volume: +では永続ボリュームクレームを使用するPodを作成します。 +GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します: ```yaml kubectl apply -f - < 3m v1.13.0 beta.kuberne ``` -Load-balancers span all zones in a cluster; the guestbook-go example -includes an example load-balanced service: +ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます: ```shell kubectl describe service guestbook | grep LoadBalancer.Ingress ``` -The output is similar to this: +結果は以下のようになります: ```shell LoadBalancer Ingress: 130.211.126.21 ``` -Set the above IP: +IPの上に設定します: ```shell export IP=130.211.126.21 ``` -Explore with curl via IP: +IPをcurlを通じて探索します: ```shell curl -s http://${IP}:3000/env | grep HOSTNAME ``` -The output is similar to this: +結果は以下のようになります: ```shell "HOSTNAME": "guestbook-44sep", ``` -Again, explore multiple times: +再び、複数回探索します: ```shell (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq ``` -The output is similar to this: +結果は以下のようになります: ```shell "HOSTNAME": "guestbook-44sep", @@ -375,11 +322,11 @@ The output is similar to this: "HOSTNAME": "guestbook-ppm40", ``` -The load balancer correctly targets all the pods, even though they are in multiple zones. +ロードバランサーは、たとえPodが複数のゾーンに存在していても、全てのPodをターゲットします。 ### クラスターの停止 -When you're done, clean up: +終了したら、クリーンアップします: GCE: From 7878c052d63e64486afb727f5364bbd005012252 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Mon, 14 Sep 2020 14:14:35 +0900 Subject: [PATCH 188/303] Apply suggestions from code review Co-authored-by: Keita Akutsu --- content/ja/docs/setup/best-practices/multiple-zones.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 41b24cb29f..5d5ba2e2f2 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -39,7 +39,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。 -*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに位置します。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 +*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。 ### ボリュームの制限 @@ -47,7 +47,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。 -* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供ない可能性があります。 +* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。 * DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 @@ -96,7 +96,7 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -それでは、現存のマスターを再利用して現存のクラスターにもう１つのノードのセットを追加しましょう。 +それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう１つのノードのセットを追加しましょう。 kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -344,4 +344,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` - From db5302c78be6284a788e1893d55b619e0bfe429f Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 17 Sep 2020 20:51:20 +0900 Subject: [PATCH 189/303] replace zenkaku numbers with hankaku numbers --- .../setup/best-practices/multiple-zones.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 5d5ba2e2f2..3f3eebd9e4 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -16,9 +16,9 @@ This page describes how to run a cluster in multiple zones. Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 -完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に１つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 +完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 -マルチゾーンサポートは故意に限定されています: １つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 +マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。 ## 機能性 @@ -49,7 +49,7 @@ Kubernetesはレプリケーションコントローラーやサービス内のP * StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。 -* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 +* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。 ## 全体の流れ @@ -71,7 +71,7 @@ AWS: curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash ``` -このステップは通常と同様にクラスターを立ち上げ、１つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 +このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。 ### ノードはラベルが付与される @@ -96,7 +96,7 @@ kubernetes-minion-a12q Ready 6m v1.13.0 ### 2つ目のゾーンにさらにノードを追加 -それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう１つのノードのセットを追加しましょう。 +それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。 kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。 GCE: @@ -113,7 +113,7 @@ KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZO ``` -ノードをもう１度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: +ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです: ```shell kubectl get nodes --show-labels @@ -228,7 +228,7 @@ kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/in ### Podがゾーンをまたがって配置される -レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、３つ目のゾーンに更なるノードを立ち上げましょう: +レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう: GCE: @@ -242,19 +242,19 @@ AWS: KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh ``` -３つのゾーンにノードがあることを確認します: +3つのゾーンにノードがあることを確認します: ```shell kubectl get nodes --show-labels ``` -シンプルなWebアプリケーションを動作する、３つのRCを持つguestbook-goの例を作成します: +シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します: ```shell find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} ``` -Podは３つの全てのゾーンにデプロイされているはずです: +Podは3つの全てのゾーンにデプロイされているはずです: ```shell kubectl describe pod -l app=guestbook | grep Node From b040c5a673594184049418d80c6d9cfcc0df060d Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Sat, 19 Sep 2020 20:51:59 +0900 Subject: [PATCH 190/303] apply a suggestion from review --- content/ja/docs/setup/best-practices/multiple-zones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/multiple-zones.md b/content/ja/docs/setup/best-practices/multiple-zones.md index 3f3eebd9e4..3281230498 100644 --- a/content/ja/docs/setup/best-practices/multiple-zones.md +++ b/content/ja/docs/setup/best-practices/multiple-zones.md @@ -14,7 +14,7 @@ This page describes how to run a cluster in multiple zones. ## 始めに -Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 +Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。 これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。 完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。 From 28a3b3028d5e3dfa6d7ff48040b2d3f2e9c37b2e Mon Sep 17 00:00:00 2001 From: inductor Date: Sat, 19 Sep 2020 12:25:35 +0900 Subject: [PATCH 191/303] delete unnecessary file --- "content/ja/docs/concepts/overview/\\" | 121 ------------------------- 1 file changed, 121 deletions(-) delete mode 100644 "content/ja/docs/concepts/overview/\\" diff --git "a/content/ja/docs/concepts/overview/\\" "b/content/ja/docs/concepts/overview/\\" deleted file mode 100644 index dbea76db1d..0000000000 --- "a/content/ja/docs/concepts/overview/\\" +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Kubernetesのコンポーネント -content_type: concept -description: > - Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。 -weight: 20 -card: - name: concepts - weight: 20 ---- - - -Kubernetesをデプロイすると、クラスターが展開されます。 -{{< glossary_definition term_id="cluster" length="all" prepend="Kubernetesクラスターは、">}} - -このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。 - -すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 - -![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) - - - - - -## コントロールプレーンコンポーネント - -コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 - -コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 -マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 - -### kube-apiserver - -{{< glossary_definition term_id="kube-apiserver" length="all" >}} - -### etcd - -{{< glossary_definition term_id="etcd" length="all" >}} - -### kube-scheduler - -{{< glossary_definition term_id="kube-scheduler" length="all" >}} - -### kube-controller-manager - -{{< glossary_definition term_id="kube-controller-manager" length="all" >}} - -コントローラーには以下が含まれます。 - - * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。 - * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。 - * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。 - * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。 - -### cloud-controller-manager - -{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} - -cloud-controller-managerは、クラウドプロバイダー固有のコントローラーのみを実行します。 -KubernetesをオンプレミスあるいはPC内での学習環境で動かす際には、クラスターにcloud container managerはありません。 - -kube-controller-managerを使用すると、cloud-controller-managerは複数の論理的に独立したコントロールループをシングルバイナリにまとめ、これが一つのプロセスとして動作します。パフォーマンスを向上させるあるいは障害に耐えるために水平方向にスケールする(一つ以上のコピーを動かす)ことができます。 - -次のコントローラーには、クラウドプロバイダーへの依存関係を持つ可能性があります。 - - * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。 - * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。 - * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 -## ノードコンポーネント {#node-components} - -ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 - -### kubelet - -{{< glossary_definition term_id="kubelet" length="all" >}} - -### kube-proxy - -{{< glossary_definition term_id="kube-proxy" length="all" >}} - -### コンテナランタイム {#container-runtime} - -{{< glossary_definition term_id="container-runtime" length="all" >}} - -## アドオン - -アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。 -アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。 - -いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。 - -### DNS - -クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/ja/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。 - -クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。 - -Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。 - - -### Web UI (ダッシュボード) - -[ダッシュボード](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。 - -### コンテナリソース監視 - -[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。 - -### クラスターレベルログ - -[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。 - - -## {{% heading "whatsnext" %}} - -* [ノード](/ja/docs/concepts/architecture/nodes/)について学ぶ -* [コントローラー](/docs/concepts/architecture/controller/)について学ぶ -* [kube-scheduler](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ -* etcdの公式 [ドキュメント](https://etcd.io/docs/)を読む - From 352a93c79767c4b01547ebface31c00184fdefa8 Mon Sep 17 00:00:00 2001 From: Akito Kobayashi Date: Tue, 8 Sep 2020 00:49:45 +0900 Subject: [PATCH 192/303] Make docs/concepts/workloads/controllers/statefulset.md follow v1.18 of the original text --- .../concepts/workloads/controllers/statefulset.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index a3b0aae707..f5625f023f 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -2,7 +2,7 @@ reviewers: title: StatefulSet content_type: concept -weight: 40 +weight: 30 --- @@ -117,6 +117,15 @@ StatefulSetは、Podのドメインをコントロールするために[Headless このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 +クラスタでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 +この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 +(DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 + +Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 + +- DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。 +- Kubernetes DNS プロバイダのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 + [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。 ここで、クラスタードメイン、Service名、StatefulSet名の選択と、それらがStatefulSetのPodのDNS名にどう影響するかの例をあげます。 @@ -150,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 -上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/user-guide/pod-states/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 +上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。 From f942cd3e9a43cd01001c53713f65871bb245727d Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:15:30 +0900 Subject: [PATCH 193/303] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index f5625f023f..5aea1ed9b9 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -117,7 +117,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless このHeadless Serviceによって管理されたドメインは`$(Service名).$(ネームスペース).svc.cluster.local`形式となり、"cluster.local"というのはそのクラスターのドメインとなります。 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 -クラスタでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 +クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 (DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 @@ -208,4 +208,3 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe * [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。 * [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。 - From 618080d5d9f8c58c84bd3a8495375c22cecb56ad Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:15:46 +0900 Subject: [PATCH 194/303] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 5aea1ed9b9..94096b0144 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -118,7 +118,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless 各Podが作成されると、Podは`$(Pod名).$(管理するServiceドメイン名)`に一致するDNSサブドメインを取得し、管理するServiceはStatefulSetの`serviceName`で定義されます。 クラスターでのDNSの設定方法によっては、新たに起動されたPodのDNS名をすぐに検索できない場合があります。 -この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリをすでに送信していた場合に発生する可能性があります。 +この動作は、クラスター内の他のクライアントが、Podが作成される前にそのPodのホスト名に対するクエリーをすでに送信していた場合に発生する可能性があります。 (DNSでは通常)ネガティブキャッシュは、Podの起動後でも、少なくとも数秒間、以前に失敗したルックアップの結果が記憶され、再利用されることを意味します。 Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 From 8da1f7fc97bd8524ffa3a9c9de415d46302b4ecc Mon Sep 17 00:00:00 2001 From: akitok Date: Fri, 18 Sep 2020 14:16:01 +0900 Subject: [PATCH 195/303] Update content/ja/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 94096b0144..08d11dbf50 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -124,7 +124,7 @@ StatefulSetは、Podのドメインをコントロールするために[Headless Podが作成された後、速やかにPodを検出する必要がある場合は、いくつかのオプションがあります。 - DNSルックアップに依存するのではなく、Kubernetes APIに直接(例えばwatchを使って)問い合わせる。 -- Kubernetes DNS プロバイダのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 +- Kubernetes DNS プロバイダーのキャッシュ時間を短縮する(これは現在30秒キャッシュされるようになっているCoreDNSのConfigMapを編集することを意味しています。)。 [制限事項](#制限事項)セクションで言及したように、ユーザーはPodのネットワークアイデンティティーのために[Headless Service](/ja/docs/concepts/services-networking/service/#headless-service)を作成する責任があります。 From 9a91829a867d0cfdf3f210a15d088351ff22ae3f Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:33:39 +0900 Subject: [PATCH 196/303] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 98a9286503..08d6a169b3 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -7,7 +7,7 @@ menu: title: "Get Started" weight: 10 post: > -

手を動かす準備はできていますか？本チュートリアルでは、Node.jsを使った簡単な"Hello World"を実行するKubernetesクラスタをビルドします。

+

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスタをビルドします。

card: name: tutorials weight: 10 @@ -15,7 +15,7 @@ card: -このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でシンプルなHello WorldのNode.jsアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 +このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でサンプルアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。 {{< note >}} [Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。 @@ -26,7 +26,7 @@ card: ## {{% heading "objectives" %}} -* Minikubeへのhello worldアプリケーションのデプロイ +* Minikubeへのサンプルアプリケーションのデプロイ * アプリケーションの実行 * アプリケーションログの確認 @@ -35,7 +35,7 @@ card: ## {{% heading "prerequisites" %}} -このチュートリアルは下記のファイルからビルドされるコンテナーイメージを提供します: +このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 {{< codenew language="js" file="minikube/server.js" >}} @@ -53,7 +53,9 @@ card: {{< kat-button >}} - {{< note >}}Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。{{< /note >}} +{{< note >}} + Minikubeをローカルにインストール済みの場合は、`minikube start`を実行してください。 +{{< /note >}} 2. ブラウザーでKubernetesダッシュボードを開いてください: @@ -67,7 +69,7 @@ card: ## Deploymentの作成 -Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。 +Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管理やネットワーキングの目的でまとめられた、1つ以上のコンテナのグループです。このチュートリアルのPodがもつコンテナは1つのみです。Kubernetesの [*Deployment*](/ja/docs/concepts/workloads/controllers/deployment/) はPodの状態を確認し、Podのコンテナが停止した場合には再起動します。DeploymentはPodの作成やスケールを管理するために推奨される方法(手段)です。 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。 @@ -113,7 +115,9 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ kubectl config view ``` - {{< note >}} `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。{{< /note >}} +{{< note >}} + `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +{{< /note >}} ## Serviceの作成 @@ -154,7 +158,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。 - "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 + アプリケーションとその応答が表示されるブラウザウィンドウが開きます。 ## アドオンの有効化 From 8ca15fb3e75f868095b960334731f473e370f925 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 4 Sep 2020 12:38:52 +0900 Subject: [PATCH 197/303] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 08d6a169b3..0802fda7ed 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -116,7 +116,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 ``` {{< note >}} - `kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +`kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 {{< /note >}} ## Serviceの作成 From fa4854c55e903034620bca4f3a186adbc930c548 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 7 Sep 2020 12:21:35 +0900 Subject: [PATCH 198/303] Update ja/docs/tutorials/hello-minikube.md --- content/ja/docs/tutorials/hello-minikube.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 0802fda7ed..311967974f 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -7,7 +7,7 @@ menu: title: "Get Started" weight: 10 post: > -

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスタをビルドします。

+

手を動かす準備はできていますか？本チュートリアルでは、サンプルアプリケーションを実行するKubernetesクラスターをビルドします。

card: name: tutorials weight: 10 @@ -37,17 +37,13 @@ card: このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 -{{< codenew language="js" file="minikube/server.js" >}} -{{< codenew language="conf" file="minikube/Dockerfile" >}} - -`docker build`コマンドについての詳細な情報は、[Dockerのドキュメント](https://docs.docker.com/engine/reference/commandline/build/)を参照してください。 -## Minikubeクラスタの作成 +## Minikubeクラスターの作成 1. **Launch Terminal** をクリックしてください @@ -103,7 +99,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` -4. クラスタイベントを確認します: +4. クラスターイベントを確認します: ```shell kubectl get events @@ -116,12 +112,12 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 ``` {{< note >}} -`kubectl`コマンドの詳細な情報は[kubectl overview](/docs/user-guide/kubectl-overview/)を参照してください。 +`kubectl`コマンドの詳細な情報は[kubectl overview](/ja/docs/reference/kubectl/overview/)を参照してください。 {{< /note >}} ## Serviceの作成 -通常、PodはKubernetesクラスタ内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。 +通常、PodはKubernetesクラスター内部のIPアドレスからのみアクセスすることができます。`hello-node`コンテナをKubernetesの仮想ネットワークの外部からアクセスするためには、Kubernetesの[*Service*](/ja/docs/concepts/services-networking/service/)としてPodを公開する必要があります。 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します: @@ -129,7 +125,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。 + `--type=LoadBalancer`フラグはServiceをクラスター外部に公開したいことを示しています。 2. 作成したServiceを確認します: @@ -247,7 +243,7 @@ Minikubeはビルトインの{{< glossary_tooltip text="アドオン" term_id="a ## クリーンアップ -クラスタに作成したリソースをクリーンアップします: +クラスターに作成したリソースをクリーンアップします: ```shell kubectl delete service hello-node From b403d06cc8f6eec2924ee38366b96b332deb3fb4 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 7 Sep 2020 13:28:54 +0900 Subject: [PATCH 199/303] Apply suggestions from code review Co-authored-by: Naoki Oketani --- content/ja/docs/tutorials/hello-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 311967974f..f8b5864f7a 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -35,7 +35,7 @@ card: ## {{% heading "prerequisites" %}} -このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナーイメージを提供します。 +このチュートリアルはNGINXを利用してすべての要求をエコーバックするコンテナイメージを提供します。 @@ -271,4 +271,3 @@ minikube delete * [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ. * [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ. - From 83558be8ad79e81300358120ea4a87b4adc83cca Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 15 Sep 2020 12:09:56 +0900 Subject: [PATCH 200/303] Apply suggestions from code review Co-authored-by: nasa9084 --- content/ja/docs/tutorials/hello-minikube.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index f8b5864f7a..530e53ffd5 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -154,7 +154,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管 5. Katacoda環境のみ：`8080`の反対側のService出力に、5桁のポート番号が表示されます。このポート番号はランダムに生成されるため、ここで使用するポート番号と異なる場合があります。ポート番号テキストボックスに番号を入力し、ポートの表示をクリックしてください。前の例の場合は、`30369`と入力します。 - アプリケーションとその応答が表示されるブラウザウィンドウが開きます。 + アプリケーションとその応答が表示されるブラウザーウィンドウが開きます。 ## アドオンの有効化 @@ -270,4 +270,3 @@ minikube delete * [Deploymentオブジェクト](/ja/docs/concepts/workloads/controllers/deployment/)について学ぶ. * [アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)について学ぶ. * [Serviceオブジェクト](/ja/docs/concepts/services-networking/service/)について学ぶ. - From 3256091cdd05117cdf5c003663ed76b9b3a127af Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Tue, 22 Sep 2020 21:52:51 +0900 Subject: [PATCH 201/303] follow 1.18 ingress.md --- .../concepts/services-networking/ingress.md | 76 ++++++++++++++++--- 1 file changed, 66 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index a2e39554c9..76bb234f7e 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -65,6 +65,7 @@ spec: - http: paths: - path: /testpath + pathType: Prefix backend: serviceName: test servicePort: 80 @@ -72,7 +73,7 @@ spec: 他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 -Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTPトラフィックに対してのルールのみサポートしています。 +Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。 ### Ingressのルール @@ -90,6 +91,61 @@ Ingressコントローラーでは、デフォルトのバックエンドが設 IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 +### パスのタイプ + +Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。 + +* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。 + +* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。 + +* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。 + + {{< note >}} + パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。 + {{< /note >}} + +#### 複数のパスとの一致 + +リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。 + +## Ingress Class + +Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。 +IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。 + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com/v1alpha + kind: IngressParameters + name: external-lb +``` + +IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。 + +### 非推奨のアノテーション + +Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールドが追加される前は、Ingressの種別はIngressの`kubernetes.io/ingress.class`アノテーションにより指定されていました。 +このアノテーションは正式に定義されたことはありませんが、Ingressコントローラーに広くサポートされています。 + +Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。 +アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。 + +### デフォルトのIngress Class + +特定のIngressClassをクラスターでのデフォルトとすることができます。 +IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。 + +{{< caution >}} +複数のIngressClassをクラスターのデフォルトに設定すると、アドミッションコントローラーは`ingressClassName`が指定されていないIngressオブジェクトの作成を防ぐようになります。クラスターのデフォルトのIngressClassを1つ以下にすることで、これを解消することができます。 +{{< /caution >}} + ## Ingressのタイプ ### 単一ServiceのIngress @@ -268,16 +324,16 @@ metadata: spec: tls: - hosts: - - sslexample.foo.com + - sslexample.foo.com secretName: testsecret-tls rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 ``` {{< note >}} @@ -288,7 +344,7 @@ spec: Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。 -Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 +Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 ## Ingressの更新 From e749fe5cb20ab279cac32c6b2bc3ea690879a4e0 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Sun, 6 Sep 2020 21:34:42 +0900 Subject: [PATCH 202/303] install-kubectl.md (ja): follow v1.18 --- .../ja/docs/tasks/tools/install-kubectl.md | 154 +++++++++--------- 1 file changed, 81 insertions(+), 73 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index e468404469..937d34e95d 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -9,7 +9,7 @@ card: --- -Kubernetesのコマンドラインツールである[kubectl](/docs/user-guide/kubectl/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理および検査を行うことができます。kubectlの操作に関する完全なリストは、[Overview of kubectl](/docs/reference/kubectl/overview/)を参照してください。 +Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/overview/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。 ## {{% heading "prerequisites" %}} @@ -26,7 +26,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと 1. 次のコマンドにより、最新リリースをダウンロードしてください: ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" ``` 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 @@ -59,7 +59,7 @@ kubectlのバージョンは、クラスターのマイナーバージョンと {{< tabs name="kubectl_install" >}} {{< tab name="Ubuntu、DebianまたはHypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https +sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list sudo apt-get update @@ -88,7 +88,7 @@ Ubuntuまたは[snap](https://snapcraft.io/docs/core/install)パッケージマ ```shell snap install kubectl --classic -kubectl version +kubectl version --client ``` {{% /tab %}} {{% tab name="Homebrew" %}} @@ -96,7 +96,7 @@ Linuxで[Homebrew](https://docs.brew.sh/Homebrew-on-Linux)パッケージマネ ```shell brew install kubectl -kubectl version +kubectl version --client ``` {{% /tab %}} {{< /tabs >}} @@ -107,7 +107,7 @@ kubectl version 1. 最新リリースをダウンロードしてください: - ``` + ```bash curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" ``` @@ -115,24 +115,24 @@ kubectl version たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: - ``` + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` 2. kubectlバイナリを実行可能にしてください。 - ``` + ```bash chmod +x ./kubectl ``` 3. バイナリをPATHの中に移動させてください。 - ``` + ```bash sudo mv ./kubectl /usr/local/bin/kubectl ``` 4. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -142,18 +142,18 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: - ``` + ```bash brew install kubectl ``` または - ``` + ```bash brew install kubernetes-cli ``` 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -163,14 +163,14 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. インストールコマンドを実行してください: - ``` + ```bash sudo port selfupdate sudo port install kubectl ``` 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```bash kubectl version --client ``` @@ -182,7 +182,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 または、`curl`をインストールされていれば、次のコマンドも使用できます: - ``` + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe ``` @@ -191,7 +191,7 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 2. バイナリをPATHに追加します 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: - ``` + ```bash kubectl version --client ``` {{< note >}} @@ -204,68 +204,76 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー 1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force + ```powershell + Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation ] ``` - {{< note >}}`DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。{{< /note >}} + {{< note >}} + `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 + {{< /note >}} インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```powershell kubectl version --client ``` - {{< note >}}アップデートする際は、手順1に示した2つのコマンドを再実行してください。{{< /note >}} + {{< note >}} + アップデートする際は、手順1に示した2つのコマンドを再実行してください。 + {{< /note >}} ### ChocolateyまたはScoopを使用してWindowsへインストールする -Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} +1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + ``` + {{% /tab %}} + {{< /tabs >}} 2. インストールしたバージョンが最新であることを確認してください: - ``` + ```powershell kubectl version --client ``` 3. ホームディレクトリへ移動してください: - ``` - cd %USERPROFILE% + ```powershell + # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 + cd ~ ``` 4. `.kube`ディレクトリを作成してください: - ``` + ```powershell mkdir .kube ``` 5. 作成した`.kube`ディレクトリへ移動してください: - ``` + ```powershell cd .kube ``` 6. リモートのKubernetesクラスターを使うために、kubectlを設定してください: - ``` + ```powershell New-Item config -type file ``` - {{< note >}}Notepadなどの選択したテキストエディターから設定ファイルを編集してください。{{< /note >}} +{{< note >}} +Notepadなどの選択したテキストエディターから設定ファイルを編集してください。 +{{< /note >}} ## Google Cloud SDKの一部としてダウンロードする @@ -274,19 +282,19 @@ Google Cloud SDKの一部として、kubectlをインストールすることも 1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。 2. `kubectl`のインストールコマンドを実行してください: - ``` + ```shell gcloud components install kubectl ``` 3. インストールしたバージョンが最新であることを確認してください: - ``` + ```shell kubectl version --client ``` ## kubectlの設定を検証する -kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。 +kubectlがKubernetesクラスターを探索し接続するために、[kubeconfigファイル](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)が必要になります。これは、[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)によりクラスターを作成した際や、Minikubeクラスターを正常にデプロイした際に自動生成されます。デフォルトでは、kubectlの設定は`~/.kube/config`に格納されています。 クラスターの状態を取得し、kubectlが適切に設定されていることを確認してください: @@ -297,7 +305,7 @@ URLのレスポンスが表示されている場合は、kubectlはクラスタ 以下のようなメッセージが表示されている場合は、kubectlは正しく設定されていないか、Kubernetesクラスターに接続できていません。 -```shell +``` The connection to the server was refused - did you specify the right host or port? ``` @@ -335,7 +343,7 @@ bash-completionは多くのパッケージマネージャーから提供され これを調べるには、シェルをリロードしてから`type _init_completion`を実行してください。コマンドが成功していればすでに設定済みです。そうでなければ、`~/.bashrc`に以下を追記してください: -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -347,21 +355,21 @@ source /usr/share/bash-completion/bash_completion - 補完スクリプトを`~/.bashrc`内でsourceしてください: - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bashrc ``` - 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください: - ```shell + ```bash kubectl completion bash >/etc/bash_completion.d/kubectl ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```shell - echo 'alias k=kubectl' >>~/.bashrc - echo 'complete -F __start_kubectl k' >>~/.bashrc - ``` +```bash +echo 'alias k=kubectl' >>~/.bashrc +echo 'complete -F __start_kubectl k' >>~/.bashrc +``` {{< note >}} bash-completionは`/etc/bash_completion.d`内のすべての補完スクリプトをsourceします。 @@ -389,19 +397,19 @@ bash-completionにはv1とv2のバージョンがあり、v1はBash 3.2(macOSの ここではBash 4.1以降の使用を前提としています。Bashのバージョンは下記のコマンドで調べることができます。 -```shell +```bash echo $BASH_VERSION ``` バージョンが古い場合、Homebrewを使用してインストールもしくはアップグレードできます。 -```shell +```bash brew install bash ``` シェルをリロードし、希望するバージョンを使用していることを確認してください。 -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -415,13 +423,13 @@ Homebrewは通常、`/usr/local/bin/bash`にインストールします。 `type _init_completion`を実行することで、bash-completionがすでにインストールされていることを確認できます。ない場合は、Homebrewを使用してインストールすることもできます: -```shell +```bash brew install bash-completion@2 ``` -このコマンドの出力で示されたように、`~/.bashrc`に以下を追記してください: +このコマンドの出力で示されたように、`~/.bash_profile`に以下を追記してください: -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -433,30 +441,30 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" すべてのシェルセッションにてkubectlの補完スクリプトをsourceできるようにしなければなりません。これを行うには複数の方法があります: -- 補完スクリプトを`~/.bashrc`内でsourceする: +- 補完スクリプトを`~/.bash_profile`内でsourceする: - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する: - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```shell - echo 'alias k=kubectl' >>~/.bashrc - echo 'complete -F __start_kubectl k' >>~/.bashrc + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 -{{< note >}} -Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 -{{< /note >}} + {{< note >}} + Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 + {{< /note >}} どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。 {{% /tab %}} @@ -465,15 +473,15 @@ Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_ Zshにおけるkubectlの補完スクリプトは`kubectl completion zsh`コマンドで生成できます。シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。 -すべてのシェルセッションで使用するには、`~/.bashrc`に以下を追記してください: +すべてのシェルセッションで使用するには、`~/.zshrc`に以下を追記してください: -```shell +```zsh source <(kubectl completion zsh) ``` kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` @@ -482,7 +490,7 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc `complete:13: command not found: compdef`のようなエラーが出力された場合は、以下を`~/.zshrc`の先頭に追記してください: -```shell +```zsh autoload -Uz compinit compinit ``` @@ -494,8 +502,8 @@ compinit ## {{% heading "whatsnext" %}} * [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/) -* クラスターの作成に関する詳細を[スタートガイド](/docs/setup/)で確認する -* [アプリケーションを起動して公開する方法を学ぶ](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください +* クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する +* [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/) +* あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください * [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する From fbb8d5950dc943d830a9f49b76c73e4439818c8c Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Wed, 16 Sep 2020 03:01:30 +0900 Subject: [PATCH 203/303] align indents under ordered lists --- .../ja/docs/tasks/tools/install-kubectl.md | 216 +++++++++--------- 1 file changed, 108 insertions(+), 108 deletions(-) diff --git a/content/ja/docs/tasks/tools/install-kubectl.md b/content/ja/docs/tasks/tools/install-kubectl.md index 937d34e95d..2ab3ca50f7 100644 --- a/content/ja/docs/tasks/tools/install-kubectl.md +++ b/content/ja/docs/tasks/tools/install-kubectl.md @@ -107,34 +107,34 @@ kubectl version --client 1. 最新リリースをダウンロードしてください: - ```bash - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + ```bash + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` - 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 + 特定のバージョンをダウンロードする場合、コマンドの`$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 - たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: + たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: - ```bash + ```bash curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` + ``` 2. kubectlバイナリを実行可能にしてください。 - ```bash - chmod +x ./kubectl - ``` + ```bash + chmod +x ./kubectl + ``` 3. バイナリをPATHの中に移動させてください。 - ```bash - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### Homebrewを使用してmacOSへインストールする @@ -142,20 +142,20 @@ macOSで[Homebrew](https://brew.sh/)パッケージマネージャーを使用 1. インストールコマンドを実行してください: - ```bash - brew install kubectl - ``` - または + ```bash + brew install kubectl + ``` + または - ```bash - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### MacPortsを使用してmacOSへインストールする @@ -163,16 +163,16 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. インストールコマンドを実行してください: - ```bash - sudo port selfupdate - sudo port install kubectl - ``` + ```bash + sudo port selfupdate + sudo port install kubectl + ``` 2. インストールしたバージョンが最新であることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ## Windowsへkubectlをインストールする {#install-kubectl-on-windows} @@ -180,20 +180,20 @@ macOSで[MacPorts](https://macports.org/)パッケージマネージャーを使 1. [こちらのリンク](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< param "fullversion" >}}をダウンロードしてください。 - または、`curl`をインストールされていれば、次のコマンドも使用できます: + または、`curl`をインストールされていれば、次のコマンドも使用できます: ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 + 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)を参照してください。 2. バイナリをPATHに追加します 3. `kubectl`のバージョンがダウンロードしたものと同じであることを確認してください: - ```bash - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)は、それ自身のバージョンの`kubectl`をPATHに追加します。Docker Desktopをすでにインストールしている場合、Docker Desktopインストーラーによって追加されたPATHの前に追加するか、Docker Desktopの`kubectl`を削除してください。 {{< /note >}} @@ -204,72 +204,73 @@ Windowsで[Powershell Gallery](https://www.powershellgallery.com/)パッケー 1. インストールコマンドを実行してください(必ず`DownloadLocation`を指定してください): - ```powershell - Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` + ```powershell + Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] + ``` - {{< note >}} - `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 - {{< /note >}} + {{< note >}} + `DownloadLocation`を指定しない場合、`kubectl`はユーザのTempディレクトリにインストールされます。 + {{< /note >}} - インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 + インストーラーは`$HOME/.kube`を作成し、設定ファイルを作成します。 2. インストールしたバージョンが最新であることを確認してください: - ```powershell - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` - {{< note >}} - アップデートする際は、手順1に示した2つのコマンドを再実行してください。 - {{< /note >}} +{{< note >}} +アップデートする際は、手順1に示した2つのコマンドを再実行してください。 +{{< /note >}} ### ChocolateyまたはScoopを使用してWindowsへインストールする 1. Windowsへkubectlをインストールするために、[Chocolatey](https://chocolatey.org)パッケージマネージャーや[Scoop](https://scoop.sh)コマンドラインインストーラーを使用することもできます。 - {{< tabs name="kubectl_win_install" >}} - {{% tab name="choco" %}} - ```powershell - choco install kubernetes-cli - ``` - {{% /tab %}} - {{% tab name="scoop" %}} - ```powershell - scoop install kubectl - ``` - {{% /tab %}} - {{< /tabs >}} + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell + choco install kubernetes-cli + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell + scoop install kubectl + ``` + {{% /tab %}} + {{< /tabs >}} + 2. インストールしたバージョンが最新であることを確認してください: - ```powershell - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` 3. ホームディレクトリへ移動してください: - ```powershell - # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 - cd ~ - ``` + ```powershell + # cmd.exeを使用している場合は cd %USERPROFILE% を実行してください。 + cd ~ + ``` 4. `.kube`ディレクトリを作成してください: - ```powershell - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. 作成した`.kube`ディレクトリへ移動してください: - ```powershell - cd .kube - ``` + ```powershell + cd .kube + ``` 6. リモートのKubernetesクラスターを使うために、kubectlを設定してください: - ```powershell - New-Item config -type file - ``` + ```powershell + New-Item config -type file + ``` {{< note >}} Notepadなどの選択したテキストエディターから設定ファイルを編集してください。 @@ -282,15 +283,15 @@ Google Cloud SDKの一部として、kubectlをインストールすることも 1. [Google Cloud SDK](https://cloud.google.com/sdk/)をインストールしてください。 2. `kubectl`のインストールコマンドを実行してください: - ```shell - gcloud components install kubectl - ``` + ```shell + gcloud components install kubectl + ``` 3. インストールしたバージョンが最新であることを確認してください: - ```shell - kubectl version --client - ``` + ```shell + kubectl version --client + ``` ## kubectlの設定を検証する @@ -355,15 +356,15 @@ source /usr/share/bash-completion/bash_completion - 補完スクリプトを`~/.bashrc`内でsourceしてください: - ```bash - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - 補完スクリプトを`/etc/bash_completion.d`ディレクトリに追加してください: - ```bash - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: ```bash @@ -443,28 +444,28 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" - 補完スクリプトを`~/.bash_profile`内でsourceする: - ```bash - echo 'source <(kubectl completion bash)' >>~/.bash_profile - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile + ``` - 補完スクリプトを`/usr/local/etc/bash_completion.d`ディレクトリに追加する: - ```bash - kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl + ``` - kubectlにエイリアスを張っている場合は、以下のようにシェルの補完を拡張して使うことができます: - ```bash - echo 'alias k=kubectl' >>~/.bash_profile - echo 'complete -F __start_kubectl k' >>~/.bash_profile - ``` + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile + ``` - kubectlをHomwbrewでインストールした場合([前述](#homebrewを使用してmacosへインストールする)のとおり)、kubectlの補完スクリプトはすでに`/usr/local/etc/bash_completion.d/kubectl`に格納されているでしょう。この場合、なにも操作する必要はありません。 - {{< note >}} - Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 - {{< /note >}} + {{< note >}} + Homebrewでインストールしたbash-completion v2は`BASH_COMPLETION_COMPAT_DIR`ディレクトリ内のすべてのファイルをsourceするため、後者の2つの方法が機能します。 + {{< /note >}} どの場合でも、シェルをリロードしたあとに、kubectlの自動補完が機能するはずです。 {{% /tab %}} @@ -506,4 +507,3 @@ compinit * [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/) * あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください * [kubectlリファレンスドキュメント](/docs/reference/kubectl/kubectl/)を参照する - From b8e399b2066d54d10793dc04d5760375ec58269b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Tue, 22 Sep 2020 23:49:14 +0900 Subject: [PATCH 204/303] Update custom-resources.md --- .../api-extension/custom-resources.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) 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 c05b35cdbc..42ac7a3604 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](/docs/user-guide/kubectl-overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 +カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 ## カスタムコントローラー @@ -31,7 +31,7 @@ weight: 10 ## カスタムリソースをクラスターに追加するべきか？ -新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 +新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: | | ------------------------------ | ---------------------------- | @@ -60,7 +60,7 @@ APIが宣言的ではない兆候として、次のものがあります: - クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る - クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる - リモートプロシージャコール(RPC)という言葉が飛び交っている - - 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い) + - 直接、大量のデータを格納している; 例えば、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い - 高帯域アクセス(持続的に毎秒数十リクエスト)が必要 - エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している - オブジェクトに対する処理が、CRUDではない @@ -84,7 +84,7 @@ APIが宣言的ではない兆候として、次のものがあります: 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください: * 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい -* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`) +* kubectlのトップレベルサポートが欲しい; 例えば、`kubectl get my-object object-name` * 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい * オブジェクトの更新を取り扱う、自動化の仕組みを書きたい * `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい @@ -107,7 +107,7 @@ CRDでは、APIサーバーの追加なしに、ユーザーが新しい種類 ## CustomResourceDefinition -[CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 +[CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)APIリソースは、カスタムリソースを定義します。CRDオブジェクトを定義することで、指定した名前、スキーマで新しいカスタムリソースが作成されます。Kubernetes APIは、作成したカスタムリソースのストレージを提供、および処理します。 CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)に従わなければなりません。 これはカスタムリソースを処理するために、独自のAPIサーバーを書くことから解放してくれますが、一般的な性質として[APIサーバーアグリゲーション](#APIサーバーアグリゲーション)と比べると、柔軟性に欠けます。 @@ -136,7 +136,7 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | CRD | アグリゲートAPI | | -------------------------- | --------------- | | プログラミングが不要で、ユーザーはCRDコントローラーとしてどの言語でも選択可能 | Go言語でプログラミングし、バイナリとイメージの作成が必要 | -| 追加のサービスは不要。カスタムリソースはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | +| 追加のサービスは不要。CRDはAPIサーバーで処理される | 追加のサービス作成が必要で、障害が発生する可能性がある | | CRDが作成されると、継続的なサポートは無い。バグ修正は通常のKubernetesマスターのアップグレードで行われる | 定期的にアップストリームからバグ修正の取り込み、リビルド、そしてアグリゲートAPIサーバーの更新が必要かもしれない | | 複数バージョンのAPI管理は不要。例えば、あるリソースを操作するクライアントを管理していた場合、APIのアップグレードと一緒に更新される | 複数バージョンのAPIを管理しなければならない。例えば、世界中に共有されている拡張機能を開発している場合 | @@ -146,17 +146,17 @@ CRDは、アグリゲートAPIと比べ、簡単に作れます。 | 機能 | 詳細 | CRD | アグリゲートAPI | | ---- | ---- | --- | --------------- | -| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | +| バリデーション | エラーを予防し、クライアントと無関係にAPIを発達させることができるようになる。これらの機能は多数のクライアントがおり、同時に全てを更新できないときに最も効果を発揮する | はい、ほとんどのバリデーションは[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)で、CRDに指定できる。その他のバリデーションは[Webhookのバリデーション](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)によりサポートされている | はい、任意のバリデーションが可能 | | デフォルト設定 | 上記を参照 | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)の`default`キーワード(1.17でGA)、または[Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)を通じて可能 (ただし、この方法は古いオブジェクトをetcdから読み込む場合には動きません) | はい | -| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | はい | +| 複数バージョニング | 同じオブジェクトを、違うAPIバージョンで利用可能にする。フィールドの名前を変更するなどのAPIの変更を簡単に行うのに役立つ。クライアントのバージョンを管理する場合、重要性は下がる | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | はい | | カスタムストレージ | 異なる性能のストレージが必要な場合(例えば、キーバリューストアの代わりに時系列データベース)または、セキュリティの分離(例えば、機密情報の暗号化、その他)| いいえ | はい | | カスタムビジネスロジック | オブジェクトが作成、読み込み、更新、また削除されるときに任意のチェック、アクションを実行する| はい、[Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を利用 | はい | -| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | はい | -| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | はい | +| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | はい | +| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | はい | | その他のサブリソース | "logs"や"exec"のような、CRUD以外の処理の追加 | いいえ | はい | -| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/run-application/update-api-object-kubectl-patch/)を参照 | いいえ | はい | +| strategic-merge-patch |`Content-Type: application/strategic-merge-patch+json`で、PATCHをサポートする新しいエンドポイント。ローカル、サーバー、どちらでも更新されうるオブジェクトに有用。さらなる情報は["APIオブジェクトをkubectl patchで決まった場所で更新"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)を参照 | いいえ | はい | | プロトコルバッファ | プロトコルバッファを使用するクライアントをサポートする新しいリソース | いいえ | はい | -| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | +| OpenAPIスキーマ | サーバーから動的に取得できる型のOpenAPI(Swagger)スキーマはあるか、許可されたフィールドのみが設定されるようにすることで、ユーザーはフィールド名のスペルミスから保護されているか、型は強制されているか(言い換えると、「文字列」フィールドに「int」を入れさせない) | はい、[OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) スキーマがベース(1.16でGA) | はい | ### 一般的な機能 @@ -166,12 +166,12 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | ---- | -------------- | | CRUD | 新しいエンドポイントが、HTTP、`kubectl`を通じて、基本的なCRUD処理をサポート | | Watch | 新しいエンドポイントが、HTTPを通じて、KubernetesのWatch処理をサポート | -| Discovery | kubectlやダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 | +| Discovery | `kubectl`やダッシュボードのようなクライアントが、自動的にリソースの一覧表示、個別表示、フィールドの編集処理を提供 | | json-patch | 新しいエンドポイントが`Content-Type: application/json-patch+json`を用いたPATCHをサポート | | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート | | HTTPS | 新しいエンドポイントがHTTPSを利用 | | ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 | -| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) | +| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用; 例えば、RBAC) | | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | @@ -205,11 +205,11 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認 ## カスタムリソースへのアクセス -Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、GoとPythonのライブラリーはサポートしています。 +Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_と_Python_のライブラリーはサポートしています。 カスタムリソースは、下記のような方法で操作できます: -- kubectl +- `kubectl` - kubernetesの動的クライアント - 自作のRESTクライアント - [Kubernetesクライアント生成ツール](https://github.com/kubernetes/code-generator)を使い生成したクライアント(生成は高度な作業ですが、一部のプロジェクトは、CRDまたはAAとともにクライアントを提供する場合があります) @@ -220,4 +220,4 @@ Kubernetesの[クライアントライブラリー](/docs/reference/using-api/cl * [Kubernetes APIをアグリゲーションレイヤーで拡張する方法](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)について学ぶ -* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)について学ぶ +* [Kubernetes APIをCustomResourceDefinitionで拡張する方法](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)について学ぶ From 53121cbed33964e2203ebc033890e7789fdc9dec Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:15:53 +0900 Subject: [PATCH 205/303] apply suggestions --- .../api-extension/custom-resources.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) 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 42ac7a3604..a35dbd4b91 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](/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 +カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。 ## カスタムコントローラー @@ -31,7 +31,7 @@ weight: 10 ## カスタムリソースをクラスターに追加するべきか？ -新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 +新しいAPIを作る場合、[APIをKubernetesクラスターAPIにアグリゲート(集約)する](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: | | ------------------------------ | ---------------------------- | @@ -60,7 +60,7 @@ APIが宣言的ではない兆候として、次のものがあります: - クライアントから"これを実行"と命令がきて、完了の返答を同期的に受け取る - クライアントから"これを実行"と命令がきて、処理IDを取得する。そして処理が完了したかどうかを、処理IDを利用して別途問い合わせる - リモートプロシージャコール(RPC)という言葉が飛び交っている - - 直接、大量のデータを格納している; 例えば、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い + - 直接、大量のデータを格納している(例、1オブジェクトあたり数kBより大きい、または数千オブジェクトより多い) - 高帯域アクセス(持続的に毎秒数十リクエスト)が必要 - エンドユーザーのデータ(画像、PII、その他)を格納している、またはアプリケーションが処理する大量のデータを格納している - オブジェクトに対する処理が、CRUDではない @@ -78,13 +78,13 @@ APIが宣言的ではない兆候として、次のものがあります: * ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい {{< note >}} -センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください +センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/ja/docs/concepts/configuration/secret/)を使ってください {{< /note >}} 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲートAPI)を使ってください: * 新しいリソースを作成、更新するために、Kubernetesのクライアントライブラリー、CLIを使いたい -* kubectlのトップレベルサポートが欲しい; 例えば、`kubectl get my-object object-name` +* kubectlのトップレベルサポートが欲しい(例、`kubectl get my-object object-name`) * 新しい自動化の仕組みを作り、新しいオブジェクトの更新をウォッチしたい、その更新を契機に他のオブジェクトのCRUDを実行したい、またはその逆を行いたい * オブジェクトの更新を取り扱う、自動化の仕組みを書きたい * `.spec`、`.status`、`.metadata`というような、Kubernetes APIの慣習を使いたい @@ -205,7 +205,7 @@ CRDでは、APIサーバーのビルトインリソースと同じ認証、認 ## カスタムリソースへのアクセス -Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_と_Python_のライブラリーはサポートしています。 +Kubernetesの[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使い、カスタムリソースにアクセスすることが可能です。全てのクライアントライブラリーがカスタムリソースをサポートしているわけでは無いですが、_Go_ と _Python_ のライブラリーはサポートしています。 カスタムリソースは、下記のような方法で操作できます: From cfb164ca3a0e706b20036b7c7b23f9a34222202b Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:33:26 +0900 Subject: [PATCH 206/303] apply suggestions --- .../extend-kubernetes/api-extension/custom-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 a35dbd4b91..3616f568c1 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 @@ -171,7 +171,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ | merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート | | HTTPS | 新しいエンドポイントがHTTPSを利用 | | ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 | -| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用; 例えば、RBAC) | +| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) | | ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック | | Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 | | UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 | From f3ee0dd2a7f027ecd852d1193dc59ac48054aeb6 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:34:58 +0900 Subject: [PATCH 207/303] Update ja/docs/tutorials/stateless-application/expose-external-ip-address.md --- .../stateless-application/expose-external-ip-address.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md index c4b76e1e3f..ca4eb8c439 100644 --- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -46,7 +46,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` -上記のコマンドにより、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)オブジェクトを作成し、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)オブジェクトを関連づけます。ReplicaSetには5つの[Pod](/ja/docs/concepts/workloads/pods/pod/)があり、それぞれHello Worldアプリケーションが起動しています。 +上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトを作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 1. Deploymentに関する情報を表示します: From 79afbcf5cc0758b77ec5d8966a067a05ec2215a4 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:38:30 +0900 Subject: [PATCH 208/303] Update ja/docs/tutorials/stateless-application/expose-external-ip-address.md --- .../stateless-application/expose-external-ip-address.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md index ca4eb8c439..2dad39cfa9 100644 --- a/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -46,7 +46,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml ``` -上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}オブジェクトを作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}オブジェクトを関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 +上記のコマンドにより、 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}を作成し、{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}を関連づけます。ReplicaSetには5つの{{< glossary_tooltip text="Pod" term_id="pod" >}}があり、それぞれHello Worldアプリケーションが起動しています。 1. Deploymentに関する情報を表示します: From e32bf8f038adcc25916ab6e8e4df3329b25893dd Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 00:04:28 +0900 Subject: [PATCH 209/303] Update operator.md --- content/ja/docs/concepts/extend-kubernetes/operator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 507463359d..e8eb71b47c 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,7 +6,7 @@ weight: 30 -オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。 +オペレーターは[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 @@ -75,7 +75,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更 ## 自分でオペレーターを書く {#writing-operator} 必要な振る舞いを実装したオペレーターがエコシステム内に無い場合、自分で作成することができます。 -[次の項目](#what-s-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。 +[次の項目](#whats-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。 オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。 From 8e231bd99f7d84f87bb50c60e3fcc2ad93c61812 Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Wed, 23 Sep 2020 01:02:12 +0900 Subject: [PATCH 210/303] apply suggestions --- content/ja/docs/concepts/extend-kubernetes/operator.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index e8eb71b47c..894b300b3c 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,8 +6,8 @@ weight: 30 -オペレーターは[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 -オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 +オペレーターは[カスタムリソース](/ja//docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 +オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 From 1b5fd47397de370c40a5159aa7580acc73c8383e Mon Sep 17 00:00:00 2001 From: Shuzo Kato <33191593+shuzokato@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:45:41 +0900 Subject: [PATCH 211/303] Update content/ja/docs/concepts/extend-kubernetes/operator.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/extend-kubernetes/operator.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 894b300b3c..e9ac2054e8 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -6,7 +6,7 @@ weight: 30 -オペレーターは[カスタムリソース](/ja//docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 +オペレーターは[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。 オペレーターは、特に[制御ループ](/ja/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。 @@ -95,4 +95,3 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更 * オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます * Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます - From f25b316b44962de280c24c130bc896651cb43705 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 25 Sep 2020 13:10:43 +0900 Subject: [PATCH 212/303] Update ja/docs/reference/_index.md --- content/ja/docs/reference/_index.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index a417966012..4276875967 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -31,16 +31,18 @@ content_type: concept ## CLIリファレンス * [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 -## 設定リファレンス +## コンポーネントリファレンス * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。 + * [kube-schedulerポリシー](/docs/reference/scheduling/policies) + * [kube-schedulerプロファイル](/docs/reference/scheduling/profiles) ## 設計のドキュメント From c2ee0d9eb1b0500c45f0ffd388067bfcceb65806 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Fri, 25 Sep 2020 12:43:07 +0900 Subject: [PATCH 213/303] Update ja/docs/concepts/services-networking/_index.md --- content/ja/docs/concepts/services-networking/_index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md index 3a33830f2f..4089dc17cf 100755 --- a/content/ja/docs/concepts/services-networking/_index.md +++ b/content/ja/docs/concepts/services-networking/_index.md @@ -1,4 +1,12 @@ --- title: "Service、負荷分散とネットワーキング" weight: 60 +description: > + Kubernetesにおけるネットワーキングの概念とリソース。 --- + +Kubernetesのネットワーキングは4つの懸念事項に対処します。 +- Pod内のコンテナは、ネットワーキングを利用してループバック経由の通信を行います。 +- クラスターネットワーキングは、異なるPod間の通信を提供します。 +- Serviceリソースは、Pod内で動作しているアプリケーションへクラスターの外部から到達可能なように露出を許可します。 +- Serviceを利用して、クラスタ内部のみで使用するServiceの公開も可能です。 From 54b79a5406578e872223775cc93dfa628fafa0b2 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Wed, 23 Sep 2020 12:55:23 +0900 Subject: [PATCH 214/303] Update ja/docs/setup/best-practices/cluster-large.md --- .../setup/best-practices/cluster-large.md | 27 ++++++++----------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 438a692fbf..5eda7e4a89 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -12,15 +12,12 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. * No more than 300000 total containers * No more than 100 pods per node -
- -{{< toc >}} ## 構築 A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. @@ -80,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### アドオンのリソース -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](httpis://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). For example: @@ -94,28 +91,26 @@ For example: memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) + * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) + * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) + * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) + * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) + * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) + * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting). - -In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster. -We welcome PRs that implement those features. +For directions on how to detect if addon containers are hitting resource limits, see the +[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). ### 少数のノードの起動の失敗を許容する From bea5c0ed6122a3141ff097246409d0f989df8cda Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Mon, 28 Sep 2020 12:03:35 +0900 Subject: [PATCH 215/303] Apply suggestions from code review Co-authored-by: nasa9084 --- content/ja/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 5eda7e4a89..bc59b1b8ee 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -77,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### アドオンのリソース -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](httpis://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). For example: From 3f0d8ecde252491171552c0440d96506045c8224 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 24 Sep 2020 13:04:19 +0900 Subject: [PATCH 216/303] Update ja/docs/tasks/run-application/force-delete-stateful-set-pod.md --- .../run-application/force-delete-stateful-set-pod.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md index 7d6830a50f..83f7b52c85 100644 --- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -31,13 +31,13 @@ StatefulSetの通常の操作では、StatefulSet Podを強制的に削除する kubectl delete pods ``` -上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前に[Podが適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)ことを保証します。 +上記がグレースフルターミネーションにつながるためには、`pod.Spec.TerminationGracePeriodSeconds`に0を指定しては**いけません**。`pod.Spec.TerminationGracePeriodSeconds`を0秒に設定することは安全ではなく、StatefulSet Podには強くお勧めできません。グレースフル削除は安全で、kubeletがapiserverから名前を削除する前にPodが[適切にシャットダウンする](/ja/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)ことを保証します。 -Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/admin/node/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: +Kubernetes(バージョン1.5以降)は、Nodeにアクセスできないという理由だけでPodを削除しません。到達不能なNodeで実行されているPodは、[タイムアウト](/docs/concepts/architecture/nodes/#node-condition)の後に`Terminating`または`Unknown`状態になります。到達不能なNode上のPodをユーザーが適切に削除しようとすると、Podはこれらの状態に入ることもあります。そのような状態のPodをapiserverから削除することができる唯一の方法は以下の通りです: - * (ユーザーまたは[Node Controller](/docs/admin/node)によって)Nodeオブジェクトが削除されます。
- * 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。
- * ユーザーによりPodを強制削除します。 +* (ユーザーまたは[Node Controller](/ja/docs/concepts/architecture/nodes/)によって)Nodeオブジェクトが削除されます。 +* 応答していないNodeのkubeletが応答を開始し、Podを終了してapiserverからエントリーを削除します。 +* ユーザーによりPodを強制削除します。 推奨されるベストプラクティスは、1番目または2番目のアプローチを使用することです。Nodeが死んでいることが確認された(例えば、ネットワークから恒久的に切断された、電源が切られたなど)場合、Nodeオブジェクトを削除します。Nodeがネットワークパーティションに苦しんでいる場合は、これを解決するか、解決するのを待ちます。パーティションが回復すると、kubeletはPodの削除を完了し、apiserverでその名前を解放します。 From 1965e44ac9e98833b2e133dee2c8ae9851eec8f2 Mon Sep 17 00:00:00 2001 From: ShotaKitazawa Date: Mon, 28 Sep 2020 14:42:27 +0900 Subject: [PATCH 217/303] fix typo --- content/ja/docs/concepts/workloads/controllers/statefulset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 08d11dbf50..1fa4c5c767 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -176,7 +176,7 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM ## アップデートストラテジー -Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。 +Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStrategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。 ### OnDelete From 6acafe23b851a7e0a6864961e0a5eab5319c9be2 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:20:00 +0900 Subject: [PATCH 218/303] Update Japanese localization on concepts/workloads/pods/pod-lifecycle.md --- .../concepts/workloads/pods/pod-lifecycle.md | 424 ++++++++---------- 1 file changed, 179 insertions(+), 245 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 1cf9df1580..aeaa355722 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,186 +6,110 @@ weight: 30 -このページではPodのライフサイクルについて説明します。 +このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 +Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 +Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。 + +Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/scheduling-eviction/)されます。PodがNodeにスケジュール(割り当て)されると、Podは停止または[終了](#pod-termination)するまでそのNode上で実行されます。 -## PodのPhase {#pod-phase} +## Podのライフタイム + +個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 +{{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。 + +Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 + +特定のPod(UIDで定義)は新しいNodeに`再スケジュール`されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 + +{{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 + +{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} + +file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。 + + +## Podのフェーズ {#pod-phase} Podの`status`項目は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)オブジェクトで、それは`phase`のフィールドがあります。 -Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。 -このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。 +Podのフェーズは、そのPodがライフサイクルのどの状態にあるかを、簡単かつ高レベルにまとめたものです。このフェーズはコンテナやPodの状態を包括的にまとめることを目的としたものではなく、また包括的なステートマシンでもありません。 -Podの各フェーズの値と意味は厳重に守られています。 -ここに記載されているもの以外に`phase`の値は存在しないと思ってください。 +Podの各フェーズの値と意味は厳重に守られています。ここに記載されているもの以外に`phase`の値は存在しないと思ってください。 これらが`phase`の取りうる値です。 値 | 概要 :-----|:----------- -`Pending` | PodがKubernetesシステムによって承認されましたが、1つ以上のコンテナイメージが作成されていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。これには時間がかかることがあります。 +`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 `Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 `Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。 `Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 -`Unknown` | 何らかの理由により、通常はPodのホストとの通信にエラーが発生したために、Podの状態を取得できませんでした。 +`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 -## Podのconditions {#pod-conditions} - -PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 -PodCondition配列の各要素には、次の6つのフィールドがあります。 - -* `lastProbeTime` は、Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。 - -* `lastTransitionTime` は、最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。 - -* `message` は、ステータスの遷移に関する詳細を示す人間向けのメッセージです。 - -* `reason` は、最後の状態遷移の理由を示す、一意のキャメルケースでの単語です。 - -* `status` は`True`と`False`、`Unknown`のうちのどれかです。 - -* `type` 次の値を取る文字列です。 - - * `PodScheduled`: PodがNodeにスケジュールされました。 - * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 - * `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 - * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 - - -## コンテナのProbe {#container-probes} - -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。 -診断を行うために、kubeletはコンテナに実装された [ハンドラー](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)を呼びます。 -Handlerには次の3つの種類があります: - -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): - コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 - -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): - コンテナのIPの特定のポートにTCPチェックを行います。 - そのポートが空いていれば診断を成功とみなします。 - -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): - コンテナのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 - レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 - -各Probe 次の3つのうちの一つの結果を持ちます: - -* Success: コンテナの診断が成功しました。 -* Failure: コンテナの診断が失敗しました。 -* Unknown: コンテナの診断が失敗し、取れるアクションがありません。 - -Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: - -* `livenessProbe`: コンテナが動いているかを示します。 - livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 - コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -* `readinessProbe`: コンテナがServiceのリクエストを受けることができるかを示します。 - readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 - initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 - コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 - startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 - startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 - コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 - -### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができれば -livenessProbeは不要です。この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 - -Probeに失敗したときにコンテナを殺したり再起動させたりするには、 -livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 - -### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 -この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、 -readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 -コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 - -コンテナがメンテナンスのために停止できるようにするには、 -livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 - -Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。 -Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。 -Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 - -### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} - -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -コンテナの起動時間が `initialDelaySeconds + failureThreshold × periodSeconds` よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。 -`periodSeconds`のデフォルトは30秒です。 - -`failureThreshold` は、livenessProbeのデフォルト値を変更せずに、コンテナが起動するのに十分な値に設定します。これによりデッドロックを防ぐことができます。 - -livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、 -[Configure Liveness, Readiness and Startup Probes](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 - -## Podとコンテナのステータス {#pod-and-container-status} - -PodとContainerのステータスについての詳細の情報は、それぞれ[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)と -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください。 -Podのステータスとして報告される情報は、現在の[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)に依存しています。 +Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 ## コンテナのステータス {#container-states} -PodがスケジューラによってNodeに割り当てられると、 -kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。 -コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。 -コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。 -Pod内のコンテナごとにStateの項目として表示されます。 +Pod全体の[Phase](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 -* `Waiting`: コンテナのデフォルトの状態。コンテナがRunningまたはTerminatedのいずれの状態でもない場合コンテナはWaitingの状態になります。Waiting状態のコンテナは引き続きイメージを取得したりSecretsを適用したりするなど必要な操作を実行します。この状態に加えてメッセージに関する情報と状態に関する理由が表示されます。 +Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。 - ```yaml - ... - State: Waiting - Reason: ErrImagePull - ... - ``` +Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。Pod内のコンテナごとにStateの項目として表示されます。 -* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。 +各状態の意味は次のとおりです。 - ```yaml - ... - State: Running - Started: Wed, 30 Jan 2019 16:46:38 +0530 - ... - ``` +### `Waiting` {#container-state-waiting} -* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。 +コンテナが`Running`または`Terminated`のいずれの状態でもない場合コンテナは`Waiting`の状態になります。Waiting状態のコンテナは引き続きコンテナイメージレジストリからイメージを取得したり{{< glossary_tooltip text="Secret" term_id="secret" >}}を適用したりするなど必要な操作を実行します。`Waiting`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Waiting`の状態である理由の要約が表示されます。 - ```yaml - ... - State: Terminated - Reason: Completed - Exit Code: 0 - Started: Wed, 30 Jan 2019 11:45:26 +0530 - Finished: Wed, 30 Jan 2019 11:45:26 +0530 - ... - ``` +### `Running` {#container-state-running} -## PodReadinessGate {#pod-readiness-gate} +`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 + +### `Terminated` {#container-state-terminated} + +`Terminated`状態のコンテナは実行されて、完了したときまたは何らかの理由で失敗したことを示します。`Terminated`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。 + +コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。 + +## コンテナの再起動ポリシー {#restart-policy} + +Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 + +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナ―の再起動バックオフタイマーをリセットします。 + +## PodのCondition {#pod-conditions} + +PodにはPodStatusがあります。それはPodが成功したかどうかの情報を持つ[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core)の配列です。 + +* `PodScheduled`: PodがNodeにスケジュールされました。 +* `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。 +* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。 +* `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 + +フィールド名 | 内容 +:--------------------|:----------- +`type` | このPodの状態の名前です。 +`status` | その状態が適用可能かどうか示します。可能な値は"`True`"と"`False`"、"`Unknown`"のうちのいずれかです。 +`lastProbeTime` | Pod Conditionが最後に確認されたときのタイムスタンプが表示されます。 +`lastTransitionTime` | 最後にPodのステータスの遷移があった際のタイムスタンプが表示されます。 +`reason` | 最後の状態遷移の理由を示す、機械可読のアッパーキャメルケースのテキストです。 +`message` | ステータスの遷移に関する詳細を示す人間向けのメッセージです。 + +## PodのReadiness {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} -追加のフィードバックやシグナルを`PodStatus`に注入できるようにしてPodのReadinessに拡張性を持たせるため、 -Kubernetes 1.11 では[Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)という機能が導入されました。 -`PodSpec`の新しいフィールド`ReadinessGate`を使用して、PodのRedinessを評価する追加の状態を指定できます。 -KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、 -ステータスはデフォルトで`False`になります。以下はその例です。 +追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletがPodのReadinessを評価する追加の状態のリストを指定します。 + +ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。 + +以下はその例です。 ```yaml Kind: Pod @@ -209,130 +133,140 @@ status: ... ``` -新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 -`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていないので、 -新しいPod Conditionは[KubeClient libraries](/docs/reference/using-api/client-libraries/)のどれかを使用する必要があります。 +PodのConditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。 -新しいPod Conditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます: +### PodのReadinessの状態 {#pod-readiness-status} + +`kubectl patch`コマンドはオブジェクトステータスのパッチ適用をまだサポートしていません。Podにこれらの`status.conditions`を設定するには、アプリケーションと{{< glossary_tooltip term_id="operator-pattern" text="operators">}}は`PATCH`アクションを使用する必要があります。[Kubernetes client library](/docs/reference/using-api/client-libraries/)を使用して、PodのReadinessのためにカスタムのPodのConditionを設定するコードを記述できます。 + +カスタムのPodのConditionが導入されるとPodは次の両方の条件に当てはまる場合**のみ**準備できていると評価されます: * Pod内のすべてのコンテナが準備完了している。 * `ReadinessGates`で指定された条件が全て`True`である。 -PodのReadinessの評価へのこの変更を容易にするために、新しいPod Conditionである`ContainersReady`が導入され、古いPodの`Ready`条件を取得します。 +Podのコンテナは準備完了ですが、少なくとも1つのカスタムのConditionが欠落しているか「False」の場合、kubeletはPodの[Condition](#pod-condition)を`ContainersReady`に設定します。 -## RestartPolicy {#restart-policy} +## コンテナのProbe {#container-probes} -PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。 -デフォルト値はAlwaysです。`restartPolicy`は、Pod内のすべてのコンテナに適用されます。 -`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。 -kubeletによって再起動される終了したコンテナは、5分後にキャップされた指数バックオフ遅延（10秒、20秒、40秒...）で再起動され、10分間の実行後にリセットされます。[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)に書かれているように、一度NodeにバインドされるとPodは別のポートにバインドされ直すことはありません。 +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [ハンドラー](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: -## Podのライフタイム {#pod-lifetime} +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 -一般にPodは人間またはコントローラーが明示的に削除するまで存在します。 -コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。 -これはPodが作成されて時間とともに終了するため、リソースリークを避けます。 +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + PodのIPの特定のポートにTCPチェックを行います。 + そのポートが空いていれば診断を成功とみなします。 -次の3種類のコントローラがあります。 +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + PodのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 + レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 -- バッチ計算などのように終了が予想されるPodに対しては、[Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用します。 - Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。 +各Probe 次の3つのうちの一つの結果を持ちます: -- 停止することを期待しないPod（たとえばWebサーバーなど）には、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)、または[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)を使用します。ReplicationControllerは`restartPolicy`がAlwaysのPodに対してのみ適切です。 +* `Success`: コンテナの診断が成功しました。 +* `Failure`: コンテナの診断が失敗しました。 +* `Unknown`: コンテナの診断が失敗し、取れるアクションがありません。 -- マシン固有のシステムサービスを提供するため、マシンごとに1つずつ実行する必要があるPodには[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を使用します。 +Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: -3種類のコントローラにはすべてPodTemplateが含まれます。 -Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。 -これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。 +* `livenessProbe`: コンテナが動いているかを示します。 + livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -Nodeが停止したりクラスタの他のNodeから切断された場合、 -Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。 +* `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。 + readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 + initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 + コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 -## 例 +* `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 + startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 + startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 + コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 -### 高度なliveness probeの例 +livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、[Liveness Probe、Readiness ProbeおよびStartup Probeを使用する](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 -Liveness Probeはkubeletによって実行されるため、 -すべてのリクエストはkubeletネットワークのnamespaceで行われます。 +### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # "host" が定義されていない場合、"PodIP"が使用されます - # host: my-host - # "scheme"が定義されていない場合、HTTPスキームが使用されます。"HTTP"と"HTTPS"のみ - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` +{{< feature-state for_k8s_version="v1.0" state="stable" >}} -### statesの例 +コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です. +この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 - * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。 - * 完了のイベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: Podの`phase`はSucceededになります。 - * Never: Podの`phase`はSucceededになります。 +Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 - * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: Podの`phase`はFailedになります。 +### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} - * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: コンテナを再起動しません。Podの`phase`はRunningのままです。 - * コンテナ1が死んでいてコンテナ2は動いている場合 - * 失敗イベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: Podの`phase`はFailedになります。 +{{< feature-state for_k8s_version="v1.0" state="stable" >}} - * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。 - * コンテナは失敗で終了します。 - * OOMイベントを記録します。 - * `restartPolicy`が、 - * Always: コンテナを再起動します。Podの`phase`はRunningのままです。 - * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。 - * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。 +Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 +この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 - * Podが実行中ですがディスクは死んでいます。 - * すべてのコンテナを殺します。 - * 適切なイベントを記録します。 - * Podの`phase`はFailedになります。 - * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 +コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 - * Podが実行中ですがNodeが切り離されました。 - * Nodeコントローラがタイムアウトを待ちます。 - * NodeコントローラがPodの`phase`をFailedにします。 - * Podがコントローラで作成されていた場合は、別の場所で再作成されます。 +{{< note >}} +Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 +{{< /note >}} + +### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 +i +コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 + +## Podの終了 {#pod-termination} + +Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 + +ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。 + +通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 + +フローの例は下のようになります。 + +1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するために`kubectl`コマンドを送信する。 +1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 + 削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。 + Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 + 1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 + {{< note >}} + `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。 + {{< /note >}} + 1. kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。 + {{< note >}} + Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。 + {{< /note >}} +1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 +1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。 +1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。 +1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。 +### Podの強制削除 {#pod-termination-forced} + +{{< caution >}} +強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 +{{< /caution >}} + +デフォルトでは、すべての削除は30秒以内に正常に行われます。`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=` オプションをサポートします。 + +`--grace-period`を`0`に設定した場合、PodはAPI serverから即座に強制的に削除されます。PodがNode上でまだ実行されている場合、その強制削除によりkubeletがトリガーされ、すぐにクリーンアップが開始されます。 + +{{< note >}} +強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。 +{{< /note >}} + +強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 + +StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 + + +### 失敗したPodのガベージコレクション {#pod-garbage-collection} + +失敗したPodは人間または{{< glossary_tooltip term_id="controller" text="controller" >}}が明示的に削除するまで存在します。 + +コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値(kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される)を超えたとき、それらのPodを削除します。これはPodが作成されて時間とともに終了するため、リソースリークを避けます。 ## {{% heading "whatsnext" %}} @@ -344,4 +278,4 @@ spec: * [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)についてもっと学ぶ - +* APIのPod/コンテナステータスの詳細情報は[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)および[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)を参照してください From f180a79342fa3ab9dd4c9a14908d510d6333e423 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:22:41 +0900 Subject: [PATCH 219/303] Delete Japanese doc concepts/workloads/pods/pod.md --- .../ja/docs/concepts/workloads/pods/pod.md | 188 ------------------ 1 file changed, 188 deletions(-) delete mode 100644 content/ja/docs/concepts/workloads/pods/pod.md diff --git a/content/ja/docs/concepts/workloads/pods/pod.md b/content/ja/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index fbb003c21b..0000000000 --- a/content/ja/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -reviewers: -title: Pod -content_type: concept -weight: 20 ---- - - - -_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。 - - - - - - -## Podとは - -_Pod_ は(クジラの小群やエンドウ豆のさやのように)、共有のストレージ/ネットワークを持つ1つ以上のコンテナ(例えばDockerコンテナ)、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。 - -Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。 - -Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。 -Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。 - -Pod内のコンテナはIPアドレスとポートの空間を共有し、 `localhost` を通じてお互いを見つけることができます 。 -また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信(IPC)を使用して互いに通信することもできます。 -異なるPodのコンテナは異なるIPアドレスを持ち、[特別な設定](/docs/concepts/policy/pod-security-policy/)がなければIPCでは通信できません。 -これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。 - -Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。 -このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。 - -[Docker](https://www.docker.com/)の用語でいえば、Podは共有namespaceと共有[ボリューム](/docs/concepts/storage/volumes/)を持つDockerコンテナのグループとしてモデル化されています。 - -個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。 -[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明しているように、Podが作成されると、一意のID(UID)が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 -Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 -特定のPod(UIDで定義)は新しいNodeに「再スケジュール」されません。 -代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます(詳細については[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)を参照してください)。 - -ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。 -そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 - -{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} - -*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。* - -## Podを用いる動機 - -### 管理 - -Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 -構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 -Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 -Pod内のコンテナに対しては、同じ場所への配置(共同スケジューリング)、命運の共有(つまり停止)、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。 - -### リソース共有と通信 - -Podは、構成要素間でのデータ共有および通信を可能にします。 - -Pod内のアプリケーションはすべて同じネットワーク名前空間(同じIPおよびポートスペース)を使用するため、 `localhost` としてお互いを「見つけて」通信できます。 -このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 -各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。 - -Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。 -詳細は[クラスターネットワーク](/docs/concepts/cluster-administration/networking/)をご覧ください。 - -Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。 -ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。 - -## Podの用途 - -Podは、垂直に統合されたアプリケーションスタック(例:LAMP)をホストするために使用できます。 -しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。 - -* コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど -* ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど -* データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど -* プロキシ、ブリッジ、およびアダプタ -* コントローラー、マネージャー、コンフィギュレーター、およびアップデーター - -個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。 - -詳細については、[The Distributed System ToolKit: Patterns for -Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)(分散システムツールキット：複合コンテナのパターン)を参照してください。 - -## 考えられる代替案 - -_単一の(Docker)コンテナで複数のプログラムを実行しないのはなぜですか？_ - -1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 -これは、ユーザーに多くの便益を提供します。 -1. ソフトウェアの依存関係を減らすため。 -個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。 -Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。 -1. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。 -1. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。 - -_アフィニティ(結合性、親和性)ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？_ - -このアプローチによって、コンテナの共同配置は提供されるでしょう。 -しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。 - - -## Podの耐久性(またはその欠如) {#pod-durability} - -Podは、耐久性のある存在として扱われることを意図していません。 -スケジューリングの失敗や、Nodeの故障には耐えられません。 -リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。 - -一般に、ユーザーはPodを直接作成する必要はありません。 -ほとんどの場合、対象がシングルトンであったとしても、[Deployments](/ja/docs/concepts/workloads/controllers/deployment/)などのコントローラーを使用するべきです。 -コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。 -[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset.md)ようなコントローラーもステートフルなPodをサポートします。 - -主要なユーザー向けのプリミティブとして集合APIを使用することは、[Borg](https://research.google.com/pubs/pub43438.html)、 [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)、[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)、[Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)などのクラスタースケジューリングシステムで比較的一般的です。 - -Podは、以下のことを容易にするためにプリミティブとして公開されています。 - -* スケジューラーとコントローラーをプラガブルにする -* コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする -* ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す -* コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する -* Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる -* アプリケーションの可用性を高める。 -即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する - -## Podの終了 {#termination-of-pods} - -Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です(対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合)。 -ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 -ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 -猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 -プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。 - -フローの例は下のようになります。 - -1. ユーザーがデフォルトの猶予期間(30秒)でPodを削除するコマンドを送信する -1. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される -1. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される -1. (3と同時に)Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する - 1. Pod内のコンテナの1つが[preStopフック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。 - 猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長して(2秒)、ステップ2が呼び出される。`preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要がある。 - 1. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに `preStop` フックが必要になることがある -1. (3と同時に)Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 -ゆっくりとシャットダウンするPodは、(サービスプロキシのような)ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない -1. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される -1. Kubeletは猶予期間を0(即時削除)に設定することでAPIサーバー上のPodの削除を終了する。 -PodはAPIから消え、クライアントからは見えなくなる - -デフォルトでは、すべての削除は30秒以内に正常に行われます。 -`kubectl delete` コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする `--grace-period=` オプションをサポートします。 -値 `0` はPodを[強制的に削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)します。 -kubectlのバージョン1.5以降では、強制削除を実行するために `--grace-period=0` と共に `--force` というフラグを追加で指定する必要があります。 - -### Podの強制削除 - -Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。 -強制削除が実行されると、API serverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 -API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。 -Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。 - -強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 -StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 - -## Podコンテナの特権モード {#privileged-mode-for-pod-containers} - -Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の `SecurityContext` の `privileged ` フラグを使用して特権モードを有効にできます。 -これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。 -コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。 -特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。 - -マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。 -それらは保留状態になります。 -ユーザーが `kubectl describe pod FooPodName` を実行すると、Podが保留状態になっている理由を確認できます。 -describeコマンド出力のイベントテーブルには、次のように表示されます。 -`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` - -マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。 -ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 -`The Pod "FooPodName" is invalid. -spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` - -## APIオブジェクト - -PodはKubernetes REST APIのトップレベルのリソースです。 -APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。 From 52a6943fee14453de588710cd54241ddc20a0d35 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Thu, 10 Sep 2020 17:40:46 +0900 Subject: [PATCH 220/303] Update pod-lifecycle.md --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index aeaa355722..84b4397990 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -24,13 +24,13 @@ Podはその生存期間に1回だけ[スケジューリング](/docs/concepts/s Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりポッドはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 -特定のPod(UIDで定義)は新しいNodeに`再スケジュール`されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 +特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 {{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} -file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。 +*file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。* ## Podのフェーズ {#pod-phase} From 295ca64c4093aca8b49ae30d8ecea35311d20695 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:18:43 +0900 Subject: [PATCH 221/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 84b4397990..a9b9260337 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,7 +6,7 @@ weight: 30 -このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 +このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 From 522318eff1630fa7009e5d0cf1ac5215b21e2dea Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:26:19 +0900 Subject: [PATCH 222/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index a9b9260337..76c4906cfd 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -55,7 +55,7 @@ Nodeが停止するか、クラスタの残りの部分から切断された場 ## コンテナのステータス {#container-states} -Pod全体の[Phase](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 +Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。 Podが{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}によってNodeに割り当てられると、kubeletは{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}を使用してコンテナの作成を開始します。コンテナの状態は`Waiting`、`Running`または`Terminated`の3ついずれかです。 From af207cb0f9acf11a59da1c352008b60316d28059 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:26:40 +0900 Subject: [PATCH 223/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 76c4906cfd..31ad35510e 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 -`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナ―の再起動バックオフタイマーをリセットします。 +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 ## PodのCondition {#pod-conditions} From d95ed85a50631ec7462e4ac5e6fedd8825844b83 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:29:35 +0900 Subject: [PATCH 224/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 31ad35510e..83b050a7ea 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -212,7 +212,6 @@ Podが削除されたときにリクエストを来ないようにするため {{< feature-state for_k8s_version="v1.16" state="alpha" >}} startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 -i コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 ## Podの終了 {#pod-termination} From 3b2f0ad46d9f89ca5b4c5d79b3fe52ec2bc66f0d Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:29:54 +0900 Subject: [PATCH 225/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 83b050a7ea..2df01fdf26 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -236,7 +236,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 {{< note >}} Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに`preStop`フックを使用して同期することを検討する。 {{< /note >}} -1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 +1. kubeletが正常な終了を開始すると同時に、コントロールプレーンは、終了中のPodをEndpoints(および有効な場合はEndpointSlice)オブジェクトから削除します。これらのオブジェクトは、{{< glossary_tooltip text="selector" term_id="selector" >}}が設定された{{< glossary_tooltip term_id="service" text="Service" >}}を表します。{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}とその他のワークロードリソースは、終了中のPodを有効なサービス中のReplicaSetとして扱いません。ゆっくりと終了するPodは、(サービスプロキシーのような)ロードバランサーが終了猶予期間が_始まる_とエンドポイントからそれらのPodを削除するので、トラフィックを継続して処理できません。 1. 猶予期間が終了すると、kubeletは強制削除を開始する。コンテナランタイムは、Pod内でまだ実行中のプロセスに`SIGKILL`を送信する。kubeletは、コンテナランタイムが非表示の`pause`コンテナを使用している場合、そのコンテナをクリーンアップします。 1. kubeletは猶予期間を0(即時削除)に設定することでAPI server上のPodの削除を終了する。 1. API serverはPodのAPIオブジェクトを削除し、クライアントからは見えなくなります。 From e99ade3e49f8351acb3520a8143dfc7c2379a45e Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Mon, 28 Sep 2020 11:37:04 +0900 Subject: [PATCH 226/303] Update content/ja/docs/concepts/workloads/pods/pod-lifecycle.md Co-authored-by: nasa9084 --- content/ja/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 2df01fdf26..8afc01295d 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム ## コンテナのProbe {#container-probes} -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [ハンドラー](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 From cc05498b41247fb18ef287a1d460f10b2efa952a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Fri, 18 Sep 2020 22:31:58 +0900 Subject: [PATCH 227/303] Update japanese services-networking/service.md to follow v1.18 of the original (English) text --- .../concepts/services-networking/service.md | 55 ++++++++++++++++--- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index e23ab9312f..be66c08c3f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -143,6 +143,14 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 +### アプリケーションプロトコル + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 + +アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[Feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 + ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。 @@ -272,7 +280,7 @@ Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主 PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数( -[makeLinkVariables関数](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 +[makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。 @@ -373,6 +381,26 @@ NodePortの使用は、Kubernetesによって完全にサポートされてい 注意点として、このServiceは`:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。 (もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、はフィルターされたNodeIPとなります。) +例えば: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app: MyApp + ports: + # デフォルトでは利便性のため、 `targetPort` は `port` と同じ値にセットされます。 + - port: 80 + targetPort: 80 + # 省略可能なフィールド + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます（デフォルトの範囲：30000-32767） + nodePort: 30007 +``` + ### LoadBalancer タイプ {#loadbalancer} 外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。 @@ -461,6 +489,17 @@ metadata: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] ``` +{{% /tab %}} +{{% tab name="IBM Cloud" %}} +```yaml +[...] +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +[...] +``` + {{% /tab %}} {{% tab name="OpenStack" %}} ```yaml @@ -532,7 +571,7 @@ TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBは 上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。 -Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。 +Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。 どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。 ```bash @@ -654,7 +693,7 @@ AWSでNetwork Load Balancerを使用するには、値を`nlb`に設定してア ``` {{< note >}} -NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。 +NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。 {{< /note >}} 古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。 @@ -663,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー `.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。 特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。 -均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。 +均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。 @@ -785,10 +824,10 @@ spec: - 80.11.12.10 ``` -## Serviceのデメリット +## Serviceの欠点 仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。 -これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。 +これについては、[Serviceのデザインプロポーザル](https://github.com/kubernetes/kubernetes/issues/1107)にてさらなる詳細を確認できます。 userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。 これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。 @@ -812,8 +851,8 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ 各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。 そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。 -コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。 -また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 +コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。 +また、Kubernetesは（例えば、管理者の介入によって）無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 ### ServiceのIPアドレス {#ips-and-vips} From bc1520e71c629043a5fb34cd690da9518a0fdbda Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 16:43:39 +0900 Subject: [PATCH 228/303] =?UTF-8?q?Translate=20"feature=20gate"=20into=20"?= =?UTF-8?q?=E3=83=95=E3=82=A3=E3=83=BC=E3=83=81=E3=83=A3=E3=83=BC=E3=82=B2?= =?UTF-8?q?=E3=83=BC=E3=83=88"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit and update link to japanese version Co-authored-by: makocchi --- content/ja/docs/concepts/services-networking/service.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index be66c08c3f..799613419c 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -149,7 +149,7 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 -アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[Feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 +アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} @@ -976,4 +976,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 - From 51a2280038ec1bfcac14a0d1814a57a86dd46ffb Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 16:47:08 +0900 Subject: [PATCH 229/303] =?UTF-8?q?Replace=20"feature=20gate"=20for=20"?= =?UTF-8?q?=E3=83=95=E3=82=A3=E3=83=BC=E3=83=81=E3=83=A3=E3=83=BC=E3=82=B2?= =?UTF-8?q?=E3=83=BC=E3=83=88"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/services-networking/service.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 799613419c..9e05423995 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -933,9 +933,9 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 -そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 +そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 #### 警告 {#caveat-sctp-overview} From 2befbab8526aad66cdd4b1f6421338d64c9feaf5 Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 18:56:43 +0900 Subject: [PATCH 230/303] Improve translation Co-authored-by: nasa9084 --- content/ja/docs/concepts/services-networking/service.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 9e05423995..bf3b04f35d 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -397,7 +397,7 @@ spec: - port: 80 targetPort: 80 # 省略可能なフィールド - # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます（デフォルトの範囲：30000-32767） + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲：30000-32767) nodePort: 30007 ``` @@ -975,4 +975,3 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理 * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 - From 25c09c5f9b2318ac1654a174119eafc988617e5c Mon Sep 17 00:00:00 2001 From: Takumi Sue <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:04:57 +0900 Subject: [PATCH 231/303] Replace em brackets for en brackets to follow the style guide Co-authored-by: nasa9084 --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index bf3b04f35d..b75ecf18f5 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -852,7 +852,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。 コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesからのマイグレーションをサポートすることも必要です)。 -また、Kubernetesは（例えば、管理者の介入によって）無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 +また、Kubernetesは(例えば、管理者の介入によって)無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。 ### ServiceのIPアドレス {#ips-and-vips} From 0f2e89919c5ab0bbe59501c6f41a6423ce8d261a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Thu, 24 Sep 2020 19:12:28 +0900 Subject: [PATCH 232/303] Replace em characters for en characters to follow the style guide --- content/ja/docs/concepts/services-networking/service.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index b75ecf18f5..2b3d6b26e0 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -397,7 +397,7 @@ spec: - port: 80 targetPort: 80 # 省略可能なフィールド - # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲：30000-32767) + # デフォルトでは利便性のため、Kubernetesコントロールプレーンはある範囲から1つポートを割り当てます(デフォルト値の範囲:30000-32767) nodePort: 30007 ``` @@ -728,7 +728,7 @@ spec: {{< /note >}} -#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション +#### Tencent Kubernetes Engine(TKE)におけるその他のCLBアノテーション 以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。 @@ -739,7 +739,7 @@ spec: # 指定したノードでロードバランサーをバインドします service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2) # 既存のロードバランサーのID - service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx + service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません service.kubernetes.io/service.extensiveParameters: "" @@ -753,7 +753,7 @@ spec: # パブリックネットワーク帯域幅の課金方法を指定します # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth) service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx - # 帯域幅の値を指定します(値の範囲：[1-2000] Mbps)。 + # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。 service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します # そうでない場合、すべてのノードが登録されます From fda183e5229c1a040aaf4c8cb2f7a8f46595978a Mon Sep 17 00:00:00 2001 From: tkms0106 <23391543+tkms0106@users.noreply.github.com> Date: Mon, 28 Sep 2020 20:14:06 +0900 Subject: [PATCH 233/303] Fix broken link not translated into Japanese yet --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index 2b3d6b26e0..e865a91712 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -702,7 +702,7 @@ NLBは特定のインスタンスクラスでのみ稼働します。サポー `.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。 特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。 -均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 +均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を設定します。 また、[内部のロードバランサー](/ja/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。 From 0e2d918ba8eb0fe11cc7112e313a943688095dbe Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 29 Sep 2020 13:17:48 +0900 Subject: [PATCH 234/303] update minikube.md for v1.18 --- .../setup/learning-environment/minikube.md | 67 +++++++++++-------- 1 file changed, 40 insertions(+), 27 deletions(-) diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index 67b0002946..54a0411132 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -50,7 +50,8 @@ MinikubeのサポートするKubernetesの機能: 特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。 2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。 -単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 + + 単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。 ```shell kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 @@ -69,6 +70,7 @@ MinikubeのサポートするKubernetesの機能: ``` `--type=NodePort`オプションで、Serviceのタイプを指定します。 + 出力はこのようになります: ``` @@ -78,6 +80,7 @@ MinikubeのサポートするKubernetesの機能: 4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。 Podが稼働しているか確認します: + ```shell kubectl get pod ``` @@ -110,19 +113,19 @@ MinikubeのサポートするKubernetesの機能: Hostname: hello-minikube-7c77b68cff-8wdzq Pod Information: - -no pod information available- + -no pod information available- Server values: - server_version=nginx: 1.13.3 - lua: 10008 + server_version=nginx: 1.13.3 - lua: 10008 Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ + client_address=172.17.0.1 + method=GET + real path=/ + query= + request_version=1.1 + request_scheme=http + request_uri=http://192.168.99.100:8080/ Request Headers: accept=*/* @@ -168,8 +171,8 @@ MinikubeのサポートするKubernetesの機能: 出力はこのようになります: ``` - Stopping local Kubernetes cluster... Stopping "minikube"... + "minikube" stopped. ``` 詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。 @@ -222,24 +225,27 @@ minikube start --kubernetes-version {{< param "fullversion" >}} #### VMドライバーの指定 -もしVMドライバーを変更したい場合は、`--vm-driver=`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 +もしVMドライバーを変更したい場合は、`--driver=`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。 ```shell -minikube start --vm-driver= +minikube start --driver= ``` Minikubeは以下のドライバーをサポートしています: {{< note >}} -サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。 +サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/)を参照してください。 {{< /note >}} -* virtualbox +* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/)) +* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) +* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (実験的) * vmwarefusion -* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) -* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) -* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) +* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) +* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) 注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。 * vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) +* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) * none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします) {{< caution >}} @@ -372,7 +378,12 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。 ### minikubeのアップグレード {#upgrading-minikube} -[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。 +macOSを使用し[Brew Package Manager](https://brew.sh/)がインストールされている場合、以下を実行します: + +```shell +brew update +brew upgrade minikube +``` ## クラスターに触れてみよう {#interacting-with-your-cluster} @@ -383,9 +394,11 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください: -`kubectl config use-context minikube`, +`kubectl config use-context minikube` -もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube` +もしくは各コマンドにコンテキストを次のように渡します: + + `kubectl get pods --context=minikube` ### ダッシュボード @@ -500,13 +513,13 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr ## 追加リンク集 -* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。 -* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。 -* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。 -* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。 -* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。 +* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。 +* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。 +* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。 +* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。 +* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/addons/)を参照してください。 * **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。 ## コミュニティ -コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。 +コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。 From a7ee415e9b1b86e2e75182d3733a71f3213d5abc Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 28 Sep 2020 13:37:05 +0900 Subject: [PATCH 235/303] Update ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md --- .../developing-cloud-controller-manager.md | 29 ++++++++----------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 5d1614ffa4..d2534086a9 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -5,35 +5,30 @@ content_type: concept -{{< feature-state for_k8s_version="v1.11" state="beta" >}} -今後のリリースで、クラウドコントローラーマネージャーはKubernetesを任意のクラウドと統合するための良い方法となります。これによりクラウドプロバイダーはKubernetesのコアリリースサイクルから独立して機能を開発できるようになります。 - -{{< feature-state for_k8s_version="1.8" state="alpha" >}} - -独自のクラウドコントローラーマネージャーを構築する方法を説明する前に、クラウドコントローラーマネージャーがKubernetesの内部でどのように機能するかに関する背景を知っておくと役立ちます。 -クラウドコントローラーマネージャーはGoインターフェースを利用する`kube-controller-manager`のコードで、任意のクラウドの実装をプラグインとして利用できるようになっています。スキャフォールディングと汎用のコントローラー実装の大部分はKubernetesのコアになりますが、[クラウドプロバイダーのインターフェイス](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)が満たされていれば提供されているクラウドプロバイダーのインターフェイスが実行されるようになります。 - -実装の詳細をもう少し掘り下げてみましょう。すべてのクラウドコントローラーマネージャーはKubernetesコアからパッケージをインポートします。唯一の違いは、各プロジェクトが利用可能なクラウドプロバイダーの情報(グローバル変数)が更新される場所である[cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63)を呼び出すことによって独自のクラウドプロバイダーを登録する点です。 - - - +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}} +## 背景 + +クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 + +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出して利用可能なクラウドプロバイダーのグローバル変数を更新し、独自のコードを登録します。 + ## 開発 ### Kubernetesには登録されていない独自クラウドプロバイダー -Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、次の3つのステップに従ってください。 +Kubernetesには登録されていない独自のクラウドプロバイダーのクラウドコントローラーマネージャーを構築するには、 1. [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)を満たす go パッケージを実装します。 -2. Kubernetesのコアにある[cloud-controller-managerのmain.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたのmain.goのテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。 -3. クラウドパッケージを `main.go` にインポートし、パッケージに [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。 +2. Kubernetesのコアにある[cloud-controller-managerの`main.go`](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)をあなたの`main.go`のテンプレートとして利用します。上で述べたように、唯一の違いはインポートされるクラウドパッケージのみです。 +3. クラウドパッケージを `main.go` にインポートし、パッケージに [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go) を実行するための `init` ブロックがあることを確認します。 -既存の独自クラウドプロバイダーの実装例を利用すると役立つでしょう。独自クラウドプロバイダーの実装例のリストは[こちら](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)にあります。 +多くのクラウドプロバイダーはオープンソースとしてコントローラーマネージャーのコードを公開しています。新たにcloud-controller-managerをスクラッチから開発する際には、既存のKubernetesには登録されていない独自クラウドプロバイダーのコントローラーマネージャーを開始地点とすることができます。 ### Kubernetesに登録されているクラウドプロバイダー -Kubernetesに登録されているクラウドプロバイダーであれば、[Daemonset](https://kubernetes.io/examples/admin/cloud/ccm-example.yaml) を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャードキュメント](/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 +Kubernetesに登録されているクラウドプロバイダーであれば、{{< glossary_tooltip term_id="daemonset" >}}を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャー](/ja/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 From a7712d814b2c5d6f03c1f2d87328c3a31da65953 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Mon, 28 Sep 2020 13:41:25 +0900 Subject: [PATCH 236/303] Update ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md --- .../administer-cluster/developing-cloud-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index d2534086a9..5d816eed32 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -13,7 +13,7 @@ content_type: concept クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 -Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出して利用可能なクラウドプロバイダーのグローバル変数を更新し、独自のコードを登録します。 +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 ## 開発 From 32aa2ece0d1dd73ed5311fc88579372a796fbf59 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Tue, 29 Sep 2020 11:47:21 +0900 Subject: [PATCH 237/303] Apply suggestions from code review Co-authored-by: nasa9084 --- .../administer-cluster/developing-cloud-controller-manager.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 5d816eed32..36e28ea455 100644 --- a/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -13,7 +13,7 @@ content_type: concept クラウドプロバイダーはKubernetesプロジェクトとは異なる速度で開発しリリースすることから、プロバイダー特有なコードを`cloud-controller-manager`バイナリから抽象化することで、クラウドベンダーはコアKubernetesコードから独立して発展することができます。 -Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは、利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 +Kubernetesプロジェクトは、(クラウドプロバイダーの)独自実装を組み込めるGoインターフェースを備えたcloud-controller-managerのスケルトンコードを提供しています。これは、クラウドプロバイダーがKubernetesコアからパッケージをインポートすることでcloud-controller-managerを実装できることを意味します。各クラウドプロバイダーは利用可能なクラウドプロバイダーのグローバル変数を更新するために`cloudprovider.RegisterCloudProvider`を呼び出し、独自のコードを登録します。 ## 開発 @@ -31,4 +31,3 @@ Kubernetesには登録されていない独自のクラウドプロバイダー Kubernetesに登録されているクラウドプロバイダーであれば、{{< glossary_tooltip term_id="daemonset" >}}を使ってあなたのクラスターで動かすことができます。詳細については[Kubernetesクラウドコントローラーマネージャー](/ja/docs/tasks/administer-cluster/running-cloud-controller/)を参照してください。 - From 73e75c7325f9bad53b8986285282d4b5d052ab0a Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 24 Sep 2020 12:35:42 +0900 Subject: [PATCH 238/303] Update ja/docs/concepts/overview/working-with-objects/labels.md --- .../docs/concepts/overview/working-with-objects/labels.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index c7ebacf360..a262dafcda 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -81,7 +81,7 @@ spec: ## ラベルセレクター {#label-selectors} -[名前とUID](/docs/user-guide/identifiers)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 +[名前とUID](/ja/docs/concepts/overview/working-with-objects/names/)とは異なり、ラベルはユニーク性を提供しません。通常、多くのオブジェクトが同じラベルを保持することを想定します。 *ラベルセレクター* を介して、クライアントとユーザーはオブジェクトのセットを指定できます。ラベルセレクターはKubernetesにおいてコアなグルーピング機能となります。 @@ -222,7 +222,7 @@ selector: #### *集合ベース* の要件指定をサポートするリソース -[`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 +[`Job`](/docs/concepts/workloads/controllers/job/)や[`Deployment`](/ja/docs/concepts/workloads/controllers/deployment/)、[`ReplicaSet`](/ja/docs/concepts/workloads/controllers/replicaset/)や[`DaemonSet`](/ja/docs/concepts/workloads/controllers/daemonset/)などの比較的新しいリソースは、*集合ベース* での要件指定もサポートしています。 ```yaml selector: matchLabels: @@ -238,6 +238,6 @@ selector: #### Nodeのセットを選択する ラベルを選択するための1つのユースケースはPodがスケジュールできるNodeのセットを制限することです。 -さらなる情報に関しては、[Node選定](/ja/docs/concepts/configuration/assign-pod-node/) のドキュメントを参照してください。 +さらなる情報に関しては、[Node選定](/docs/concepts/scheduling-eviction/assign-pod-node/) のドキュメントを参照してください。 From 384bb3de92a1e8b6a07819cbae83e49785d554c7 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sat, 19 Sep 2020 17:48:58 +0900 Subject: [PATCH 239/303] translated kubectl overview.md --- content/ja/docs/reference/kubectl/overview.md | 116 +++++++++++------- 1 file changed, 71 insertions(+), 45 deletions(-) diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md index c45e055b41..c291da9e44 100644 --- a/content/ja/docs/reference/kubectl/overview.md +++ b/content/ja/docs/reference/kubectl/overview.md @@ -1,4 +1,5 @@ --- +reviewers: title: kubectlの概要 content_type: concept weight: 20 @@ -8,9 +9,9 @@ card: --- -`kubectl`は、Kubernetesクラスターを制御するためのコマンドラインツールです。`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。 +`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/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/)をご覧ください。 -この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/kubectl/install/)をご覧ください。 @@ -29,11 +30,11 @@ kubectl [command] [TYPE] [NAME] [flags] * `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。 - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。 @@ -49,7 +50,7 @@ kubectl [command] [TYPE] [NAME] [flags] * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。 - * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/docs/concepts/configuration/overview/#general-configuration-tips)。
+ * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。
例: `kubectl get pod -f ./pod.yaml` * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。
@@ -64,41 +65,59 @@ kubectl [command] [TYPE] [NAME] [flags] 以下の表に、`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-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを表示します。 +`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つ以上のフィールドを更新します。 -`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のリーカルポートを、Podに転送します。 +`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` | ファイルや標準出力から、リソースを置き換えます。 -`run` | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--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のサイズを更新します。 +`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/user-guide/kubectl/)リファレンスドキュメントを参照してください。 +コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。 ## リソースタイプ {#resource-types} 以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。 -(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確です。) +(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。) | リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 | |---|---|---|---|---| @@ -154,7 +173,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 出力オプション -ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントをご覧ください。 +ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。 ### 出力のフォーマット @@ -187,13 +206,12 @@ kubectl [command] [TYPE] [NAME] -o kubectl get pod web-pod-13je7 -o yaml ``` -各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントを参照してください。 +各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。 #### カスタムカラム {#custom-columns} カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=`または`-o custom-columns-file=`のようにテンプレートファイルを使用するかを選択できます。 - ##### 例 インラインで定義する例は、以下の通りです。 @@ -214,10 +232,9 @@ kubectl get pods -o custom-columns-file=template.txt NAME RSRC metadata.name metadata.resourceVersion ``` - どちらのコマンドを実行した場合でも、以下の結果を得ます。 -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -228,22 +245,21 @@ submit-queue 610995 つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。 これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。 -この機能は、`kubectl`1.11以降ではデフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。 +この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。 ##### 例 Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。 - ```shell kubectl get pods --server-print=false ``` 以下のように出力されます。 -```shell -NAME READY STATUS RESTARTS AGE -pod-name 1/1 Running 0 1m +``` +NAME AGE +pod-name 1m ``` ### オブジェクトリストのソート @@ -314,6 +330,7 @@ kubectl describe pods/ # ReplicationController が管理しているすべてのPodの詳細を表示します。 # ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。 +kubectl describe pods # すべてのPodの詳細を表示します。 kubectl describe pods @@ -329,8 +346,8 @@ kubectl describe pods # pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。 kubectl delete -f pod.yaml -# name=というラベルを持つPodとServiceをすべて削除します。 -kubectl delete pods,services -l name= +# '='というラベルを持つPodとServiceをすべて削除します。 +kubectl delete pods,services -l = # 初期化されていないPodを含む、すべてのPodを削除します。 kubectl delete pods --all @@ -340,14 +357,13 @@ kubectl delete pods --all ```shell # Pod から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。 -kubectl exec date +kubectl exec -- date # Pod のコンテナ から、'date'を実行している時の出力を取得します。 -kubectl exec -c date +kubectl exec -c -- date # インタラクティブな TTY を取得し、Pod から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。 -Get an interactive TTY and run /bin/bash from pod . By default, output is from the first container. -kubectl exec -ti /bin/bash +kubectl exec -ti -- /bin/bash ``` `kubectl logs` - Pod内のコンテナのログを表示します。 @@ -378,16 +394,20 @@ cat service.yaml | kubectl diff -f - # 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに # プレフィックス"kubectl-"で始まる名前を付けます。 cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # このプラグインは、"hello world"という単語を表示します。 echo "hello world" - -# プラグインを書いたら、実行可能にします。 -sudo chmod +x ./kubectl-hello +``` +プラグインを書いたら、実行可能にします。 +```bash +chmod a+x ./kubectl-hello # さらに、PATH内の場所に移動させます。 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin # これでkubectlプラグインを作成し、"インストール"できました。 # 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。 @@ -398,14 +418,16 @@ hello world ``` ```shell -# 単純にPATHから削除することで、プラグインを"アンインストール"できます。 +# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。 sudo rm /usr/local/bin/kubectl-hello ``` -`kubectl`で利用可能なプラグインをすべて表示するには、以下のように`kubectl plugin list`サブコマンドを使用します。 +`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。 + ```shell kubectl plugin list ``` +出力は以下のようになります。 ``` The following kubectl-compatible plugins are available: @@ -413,9 +435,10 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。 ```shell -# このコマンドで、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。 -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。 kubectl plugin list ``` ``` @@ -433,14 +456,19 @@ error: one plugin warning was found ```shell cat ./kubectl-whoami +``` +次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。 +The next few examples assume that you already made `kubectl-whoami` have +the following contents: +```shell #!/bin/bash # このプラグインは、`kubectl config`コマンドを使って # 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。 -kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}' +kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -上記のプラグインを実行すると、以下のように、KUBECONFIGファイルの中で現在選択されているユーザーを含む出力が得られます。 +上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。 ```shell # ファイルを実行可能にします。 @@ -453,10 +481,8 @@ kubectl whoami Current user: plugins-user ``` -プラグインについてより詳しく知りたい場合は、[example cli plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。 - - ## {{% heading "whatsnext" %}} -[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。 +* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。 +* プラグインについてより詳しく知りたい場合は, [example cli plugin](https://github.com/kubernetes/sample-cli-plugin)を御覧ください。 From 07ec30894b927cca7cb1e2e97569ecff1245a1a4 Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Sat, 26 Sep 2020 00:12:08 +0900 Subject: [PATCH 240/303] deleted reviewers --- content/ja/docs/reference/kubectl/overview.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md index c291da9e44..71ce1844ec 100644 --- a/content/ja/docs/reference/kubectl/overview.md +++ b/content/ja/docs/reference/kubectl/overview.md @@ -1,5 +1,4 @@ --- -reviewers: title: kubectlの概要 content_type: concept weight: 20 From 7617c96d531e52b4cd2fe9af73d721f8beec1b00 Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Tue, 29 Sep 2020 13:00:12 +0900 Subject: [PATCH 241/303] Update ja/docs/reference/access-authn-authz/authentication.md --- .../reference/access-authn-authz/authentication.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 297bcce9d0..1c7e0bb1d1 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -13,7 +13,15 @@ weight: 10 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 -通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 +クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 + +- 秘密鍵を配布する管理者 +- KyestoneやGoogle Accountsのようなユーザーストア +- ユーザー名とパスワードのリストを持つファイル + +これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 + +APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(e.g., “/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 @@ -236,7 +244,7 @@ Secretは常にbase64でエンコードされるため、これらの値もbase6 重要なのは、APIサーバーはOAuth2クライアントではなく、ある単一の発行者を信頼するようにしか設定できないことです。これにより、サードパーティーに発行されたクレデンシャルを信頼せずに、Googleのようなパブリックプロバイダーを使用することができます。複数のOAuthクライアントを利用したい管理者は、`azp`クレームをサポートしているプロバイダや、あるクライアントが別のクライアントに代わってトークンを発行できるような仕組みを検討する必要があります。 -KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。 +KubernetesはOpenID Connect IDプロバイダーを提供していません。既存のパブリックなOpenID Connect IDプロバイダー(Googleや[その他](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)など)を使用できます。もしくは、CoreOS [dex](https://github.com/coreos/dex)、[Keycloak](https://github.com/keycloak/keycloak)、CloudFoundry[UAA](https://github.com/cloudfoundry/uaa)、Tremolo Securityの[OpenUnison](https://github.com/tremolosecurity/openunison)など、独自のIDプロバイダーを実行することもできます。 IDプロバイダーがKubernetesと連携するためには、以下のことが必要です。 @@ -319,7 +327,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。 * `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです * `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です -設定ファイルは、[kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)のファイル形式を使用します。 +設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。 ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。 ```yaml From be90e20b411055c38def426a6bfcc44bac77e3ee Mon Sep 17 00:00:00 2001 From: YukiKasuya Date: Thu, 1 Oct 2020 09:34:29 +0900 Subject: [PATCH 242/303] Update ja/docs/reference/access-authn-authz/authentication.md --- content/ja/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 1c7e0bb1d1..5e6b47054d 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -16,7 +16,7 @@ weight: 10 クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 - 秘密鍵を配布する管理者 -- KyestoneやGoogle Accountsのようなユーザーストア +- KeystoneやGoogle Accountsのようなユーザーストア - ユーザー名とパスワードのリストを持つファイル これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 From efe076f908b7cee279b8a048316898a41e797b94 Mon Sep 17 00:00:00 2001 From: yu-kasuya Date: Fri, 2 Oct 2020 10:03:13 +0900 Subject: [PATCH 243/303] Apply suggestions from code review Co-authored-by: nasa9084 --- .../ja/docs/reference/access-authn-authz/authentication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 5e6b47054d..98cafd2735 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -13,7 +13,7 @@ weight: 10 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。 -クラスターと独立したサービスは通常のユーザーを以下の方法で管理することを想定しています。 +クラスターから独立したサービスは通常のユーザーを以下の方法で管理することを想定されています。 - 秘密鍵を配布する管理者 - KeystoneやGoogle Accountsのようなユーザーストア @@ -21,7 +21,7 @@ weight: 10 これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。 -APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(e.g., “/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 +APIコールを介して通常のユーザーを追加できませんが、クラスターの認証局(CA)に署名された有効な証明書で表すユーザーは認証済みと判断されます。この構成では、Kubernetesは証明書の‘subject’内にある一般的な名前フィールド(例えば、“/CN=bob”)からユーザー名を特定します。そこから、ロールベースアクセス制御(RBAC)サブシステムは、ユーザーがあるリソースにおける特定の操作を実行するために認証済みかどうか特定します。詳細は、 [証明書要求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)内の通常のユーザーの題目を参照してください。 対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報の集合に紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 From 55393e833f9cae25683109037f4ebcd4bf659a84 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 29 Sep 2020 21:36:35 +0900 Subject: [PATCH 244/303] update cassandra.md for v1.18 --- .../stateful-application/cassandra.md | 48 +++++++++++-------- 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md index 32b215e62d..23b2d0967e 100644 --- a/content/ja/docs/tutorials/stateful-application/cassandra.md +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -5,14 +5,18 @@ weight: 30 --- -このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。データベースの一種であるCassandraには、データの耐久性(アプリケーションの*状態*)を提供するために永続ストレージが必要です。この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 +このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。 +データベースの一種であるCassandraには、データの耐久性(アプリケーションの_状態_)を提供するために永続ストレージが必要です。 +この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 -*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 +*StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。 +このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 {{< note >}} -CassandraとKubernetesは、ともにクラスターのメンバーを表すために*ノード*という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(*ring*と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 +CassandraとKubernetesは、ともにクラスターのメンバーを表すために_ノード_という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(_ring_と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 -Cassandraノードが開始すると、*シードリスト*を使ってring上の他のノードの検出が始まります。このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 +Cassandraノードが開始すると、_シードリスト_を使ってring上の他のノードの検出が始まります。 +このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 {{< /note >}} @@ -34,7 +38,8 @@ Cassandraノードが開始すると、*シードリスト*を使ってring上 ### Minikubeのセットアップに関する追加の設定手順 {{< caution >}} -[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください。 +[Minikube](/ja/docs/getting-started-guides/minikube/)は、デフォルトでは1024MiBのメモリと1CPUに設定されます。 +デフォルトのリソース設定で起動したMinikubeでは、このチュートリアルの実行中にリソース不足のエラーが発生してしまいます。このエラーを回避するためにはMinikubeを次の設定で起動してください: ```shell minikube start --memory 5120 --cpus=4 @@ -48,7 +53,7 @@ minikube start --memory 5120 --cpus=4 Kubernetesでは、{{< glossary_tooltip text="Service" term_id="service" >}}は同じタスクを実行する{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合を表します。 -以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます。 +以下のServiceは、Cassandra Podとクラスター内のクライアント間のDNSルックアップに使われます: {{< codenew file="application/cassandra/cassandra-service.yaml" >}} @@ -82,12 +87,13 @@ cassandra ClusterIP None 9042/TCP 45s 以下に示すStatefulSetマニフェストは、3つのPodからなるCassandra ringを作成します。 {{< note >}} -この例ではMinikubeのデフォルトのプロビジョナーを使用しています。クラウドを使用している場合、StatefulSetを更新してください。 +この例ではMinikubeのデフォルトのプロビジョナーを使用しています。 +クラウドを使用している場合、StatefulSetを更新してください。 {{< /note >}} {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} -`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します。 +`cassandra-statefulset.yaml`ファイルから、CassandraのStatefulSetを作成します: ```shell # cassandra-statefulset.yaml を編集せずにapplyできる場合は、このコマンドを使用してください @@ -110,7 +116,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl get statefulset cassandra ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` NAME DESIRED CURRENT AGE @@ -125,7 +131,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl get pods -l="app=cassandra" ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ```shell NAME READY STATUS RESTARTS AGE @@ -133,7 +139,7 @@ kubectl apply -f cassandra-statefulset.yaml cassandra-1 0/1 ContainerCreating 0 8s ``` - 3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します。 + 3つすべてのPodのデプロイには数分かかる場合があります。デプロイが完了すると、同じコマンドは次のような結果を返します: ``` NAME READY STATUS RESTARTS AGE @@ -148,7 +154,7 @@ kubectl apply -f cassandra-statefulset.yaml kubectl exec -it cassandra-0 -- nodetool status ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` Datacenter: DC1-K8Demo @@ -171,7 +177,8 @@ kubectl apply -f cassandra-statefulset.yaml kubectl edit statefulset cassandra ``` - このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。以下の例は、StatefulSetファイルの抜粋です。 + このコマンドを実行すると、ターミナルでエディタが起動します。変更が必要な行は`replicas`フィールドです。 + 以下の例は、StatefulSetファイルの抜粋です: ```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, @@ -197,13 +204,13 @@ kubectl apply -f cassandra-statefulset.yaml これで、StatefulSetが4つのPodを実行するようにスケールされました。 -1. CassandraのStatefulSetを取得して、変更を確かめます。 +1. CassandraのStatefulSetを取得して、変更を確かめます: ```shell kubectl get statefulset cassandra ``` - 結果は次のようになるはずです。 + 結果は次のようになるはずです: ``` NAME DESIRED CURRENT AGE @@ -214,13 +221,14 @@ kubectl apply -f cassandra-statefulset.yaml ## {{% heading "cleanup" %}} -StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。 +StatefulSetを削除したりスケールダウンしても、StatefulSetに関係するボリュームは削除されません。 +StatefulSetに関連するすべてのリソースを自動的に破棄するよりも、データの方がより貴重であるため、安全のためにこのような設定になっています。 {{< warning >}} ストレージクラスやreclaimポリシーによっては、*PersistentVolumeClaim*を削除すると、関連するボリュームも削除される可能性があります。PersistentVolumeClaimの削除後にもデータにアクセスできるとは決して想定しないでください。 {{< /warning >}} -1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します。 +1. 次のコマンドを実行して(単一のコマンドにまとめています)、CassandraのStatefulSetに含まれるすべてのリソースを削除します: ```shell grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ @@ -230,7 +238,7 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 && kubectl delete persistentvolumeclaim -l app=cassandra ``` -1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します。 +1. 次のコマンドを実行して、CassandraをセットアップしたServiceを削除します: ```shell kubectl delete service -l app=cassandra @@ -240,7 +248,8 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)をベースにしており、OpenJDK 8が含まれています。 -このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 +このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。 +環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 | 環境変数 | デフォルト値 | | ------------------------ |:---------------: | @@ -258,4 +267,3 @@ StatefulSetを削除したりスケールダウンしても、StatefulSetに関 * カスタムの[Seed Providerの設定](https://git.k8s.io/examples/cassandra/java/README.md)についてもっと学ぶ。 - From ace9f7b0ed92648bc13054f90c954de5e0c257fd Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Thu, 8 Oct 2020 10:49:34 +0900 Subject: [PATCH 245/303] update cassandra.md for v1.18 --- content/ja/docs/tutorials/stateful-application/cassandra.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md index 23b2d0967e..c5f8ed3986 100644 --- a/content/ja/docs/tutorials/stateful-application/cassandra.md +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -6,16 +6,16 @@ weight: 30 このチュートリアルでは、[Apache Cassandra](http://cassandra.apache.org/)をKubernetes上で実行する方法を紹介します。 -データベースの一種であるCassandraには、データの耐久性(アプリケーションの_状態_)を提供するために永続ストレージが必要です。 +データベースの一種であるCassandraには、データの耐久性(アプリケーションの _状態_)を提供するために永続ストレージが必要です。 この例では、カスタムのCassandraのseed providerにより、Cassandraクラスターに参加した新しいCassandraインスタンスを検出できるようにします。 *StatefulSet*を利用すると、ステートフルなアプリケーションをKubernetesクラスターにデプロイするのが簡単になります。 このチュートリアルで使われている機能のより詳しい情報は、[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)を参照してください。 {{< note >}} -CassandraとKubernetesは、ともにクラスターのメンバーを表すために_ノード_という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター(_ring_と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 +CassandraとKubernetesは、ともにクラスターのメンバーを表すために _ノード_ という用語を使用しています。このチュートリアルでは、StatefulSetに属するPodはCassandraのノードであり、Cassandraクラスター( _ring_ と呼ばれます)のメンバーでもあります。これらのPodがKubernetesクラスター内で実行されるとき、Kubernetesのコントロールプレーンは、PodをKubernetesの{{< glossary_tooltip text="Node" term_id="node" >}}上にスケジュールします。 -Cassandraノードが開始すると、_シードリスト_を使ってring上の他のノードの検出が始まります。 +Cassandraノードが開始すると、 _シードリスト_ を使ってring上の他のノードの検出が始まります。 このチュートリアルでは、Kubernetesクラスター内に現れた新しいCassandra Podを検出するカスタムのCassandraのseed providerをデプロイします。 {{< /note >}} From c85942837b2da18383bef425821bcccfaa03c66c Mon Sep 17 00:00:00 2001 From: Takaaki Fujii Date: Tue, 6 Oct 2020 00:10:50 +0900 Subject: [PATCH 246/303] finished translating cheartsheet.md --- .../ja/docs/reference/kubectl/cheatsheet.md | 67 +++++++++++++------ 1 file changed, 45 insertions(+), 22 deletions(-) diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index 1ebe1deea6..2cb17247c5 100644 --- a/content/ja/docs/reference/kubectl/cheatsheet.md +++ b/content/ja/docs/reference/kubectl/cheatsheet.md @@ -8,7 +8,7 @@ card: -[Kubectl概要](/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。 +[Kubectl概要](/ja/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。 このページは`kubectl`コマンドの概要です。 @@ -37,14 +37,14 @@ complete -F __start_kubectl k ### ZSH ```bash -source <(kubectl completion zsh) # 現在のzshシェルでコマンド補完を設定します +source <(kubectl completion zsh) # 現在のzshシェルにコマンド補完を設定します echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。 ``` ## Kubectlコンテキストの設定 `kubectl`がどのKubernetesクラスターと通信するかを設定します。 -設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。 +設定ファイル詳細については[kubeconfigを使用した複数クラスターとの認証](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)をご覧ください。 ```bash kubectl config view # マージされたkubeconfigの設定を表示します。 @@ -63,7 +63,7 @@ kubectl config get-contexts # コンテキストのリ kubectl config current-context # 現在のコンテキストを表示します kubectl config use-context my-cluster-name # デフォルトのコンテキストをmy-cluster-nameに設定します -# basic認証をサポートする新たなクラスターをkubeconfigに追加します +# basic認証をサポートする新たなユーザーをkubeconfigに追加します kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword # 現在のコンテキストでkubectlのサブコマンドのネームスペースを永続的に変更します @@ -152,7 +152,7 @@ kubectl get pod my-pod -o yaml # PodのYAMLを表示します kubectl describe nodes my-node kubectl describe pods my-pod -# 名前順にソートしたリストを表示します +# 名前順にソートしたServiceのリストを表示します kubectl get services --sort-by=.metadata.name # Restartカウント順にPodのリストを表示します @@ -165,33 +165,33 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# 'ca.crt'のようなピリオドが含まれるキーの値を取得します +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # すべてのワーカーノードを取得します（セレクターを使用して、 # 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します） kubectl get node --selector='!node-role.kubernetes.io/master' -# 現在のネームスペースでrunning状態のPodをリストを表示します +# 現在のネームスペースでrunning状態のPodのリストを表示します kubectl get pods --field-selector=status.phase=Running -# すべてのノードのExternal IPをリストを表示します +# すべてのノードのExternal IPのリストを表示します kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' # 特定のRCに属するPodの名前のリストを表示します # `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です - sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) # すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します - kubectl get pods --show-labels # どのノードがready状態か確認します - JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" # Podで現在使用中のSecretをすべて表示します - kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq # すべてのPodのInitContainerのコンテナIDのリストを表示します @@ -199,15 +199,25 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 # タイムスタンプでソートされたEventのリストを表示します - kubectl get events --sort-by=.metadata.creationTimestamp # クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。 kubectl diff -f ./my-manifest.yaml + +# Nodeから返されるすべてのキーをピリオド区切りの階層表記で生成します。 +# 複雑にネストされたJSON構造をもつキーを指定したい時に便利です +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# Pod等から返されるすべてのキーをピリオド区切り階層表記で生成します。 +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' ``` ## リソースのアップデート +<<<<<<< HEAD +======= + +>>>>>>> 8d357bf1e (finished translating cheartsheet.md) ```bash kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします kubectl rollout history deployment/frontend # frontend Deploymentの改訂履歴を確認します @@ -253,7 +263,6 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", ``` ## リソースの編集 - 任意のエディターでAPIリソースを編集します。 ```bash @@ -294,10 +303,10 @@ kubectl logs -f my-pod # Podのログをストリ kubectl logs -f my-pod -c my-container # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力) kubectl logs -f -l name=myLabel --all-containers # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力) kubectl run -i --tty busybox --image=busybox -- sh # Podをインタラクティブシェルとして実行します -kubectl run nginx --image=nginx --restart=Never -n +kubectl run nginx --image=nginx -n mynamespace # 特定のネームスペースでnginx Podを実行します -kubectl run nginx --image=nginx --restart=Never # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます ---dry-run -o yaml > pod.yaml +kkubectl run nginx --image=nginx # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます +--dry-run=client -o yaml > pod.yaml kubectl attach my-pod -i # 実行中のコンテナに接続します kubectl port-forward my-pod 5000:6000 # ローカルマシンのポート5000を、my-podのポート6000に転送します kubectl exec my-pod -- ls / # 既存のPodでコマンドを実行(単一コンテナの場合) @@ -308,9 +317,9 @@ kubectl top pod POD_NAME --containers # 特定のPodとそのコ ## ノードおよびクラスターとの対話処理 ```bash -kubectl cordon my-node # my-nodeにスケーリングされないように設定します +kubectl cordon my-node # my-nodeをスケーリングされないように設定します kubectl drain my-node # メンテナンスの準備としてmy-nodeで動作中のPodを空にします -kubectl uncordon my-node # my-nodeにスケーリングされるように設定します +kubectl uncordon my-node # my-nodeをスケーリングされるように設定します kubectl top node my-node # 特定のノードのメトリクスを表示します kubectl cluster-info # Kubernetesクラスターのマスターとサービスのアドレスを表示します kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします @@ -322,7 +331,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### リソースタイプ -サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 +サポートされているすべてのリソースタイプを、それらが[API group](/ja/docs/concepts/overview/kubernetes-api/#api-groups)か[Namespaced](/ja/docs/concepts/overview/working-with-objects/namespaces)、[Kind](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)に関わらずその短縮名をリストします。 ```bash kubectl api-resources @@ -345,7 +354,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの 出力フォーマット | 説明 ---------------- | ----------- -`-o=custom-columns=` | カスタムカラムを使用してコンマ区切りのテーブルを表示します +`-o=custom-columns=` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します `-o=custom-columns-file=` | ``ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します `-o=json` | JSON形式のAPIオブジェクトを出力します `-o=jsonpath=