Merge branch 'master' into dev-1.20

.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

OWNERS_ALIASES

@@ -120,10 +120,11 @@ aliases:
     - bells17
     # cstoku
     - inductor
+    - kakts
     - makocchi-git
     # MasayaAoyama
     - nasa9084
-    - oke-py
+    # oke-py
   sig-docs-ko-owners: # Admins for Korean content
     - ClaudiaJKang
     - gochist

README-ja.md

@@ -4,34 +4,100 @@
 
 このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
 
-## Hugoを使ってローカル環境でWebサイトを動かす
+# リポジトリの使い方
 
-Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
+Hugo(Extended version)を使用してWebサイトをローカルで実行することも、コンテナランタイムで実行することもできます。コンテナランタイムを使用することを強くお勧めします。これにより、本番Webサイトとのデプロイメントの一貫性が得られます。
 
-Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+## 前提条件
 
-```bash
+このリポジトリを使用するには、以下をローカルにインストールする必要があります。
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo(Extended version)](https://gohugo.io/)
+- [Docker](https://www.docker.com/)などのコンテナランタイム
+
+開始する前に、依存関係をインストールしてください。リポジトリのクローンを作成し、ディレクトリに移動します。
+
+```
 git clone https://github.com/kubernetes/website.git
 cd website
+```
+
+KubernetesのWebサイトではDocsyというHugoテーマを使用しています。コンテナでWebサイトを実行する場合でも、以下を実行して、サブモジュールおよびその他の開発依存関係をプルすることを強くお勧めします。
+
+```
+# pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
 
-**注意:** Kubernetesのウェブサイトでは[DocsyというHugoのテーマ](https://github.com/google/docsy#readme)を使用しています。リポジトリを更新していない場合、 `website/themes/docsy`ディレクトリは空です。 このサイトはテーマのローカルコピーなしでは構築できません。
+## コンテナを使ってウェブサイトを動かす
 
-テーマをアップデートするには以下のコマンドを実行します:
+コンテナ内でサイトを構築するには、以下を実行してコンテナイメージを構築し、実行します。
 
-```bash
+```
-git submodule update --init --recursive --depth 1
+make container-image
+make container-serve
 ```
 
-サイトをローカルでビルドしてテストするには以下のコマンドを実行します:
+お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+
+## Hugoを使ってローカル環境でWebサイトを動かす
+
+[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じExtended versionのHugoをインストールするようにしてください。
+
+ローカルでサイトを構築してテストするには、次のコマンドを実行します。
 
 ```bash
-hugo server --buildFuture
+# install dependencies
+npm ci
+make serve
 ```
 
 これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
 
+## トラブルシューティング
+
+### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
+
+Hugoは、技術的な理由から2種類のバイナリがリリースされています。現在のウェブサイトは**Hugo Extended**バージョンのみに基づいて運営されています。[リリースページ](https://github.com/gohugoio/hugo/releases)で名前に「extended」が含まれるアーカイブを探します。確認するには、`hugo version`を実行し、「extended」という単語を探します。
+
+### macOSにてtoo many open filesというエラーが表示される
+
+macOS上で`make serve`を実行した際に以下のエラーが表示される場合
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+OS上で同時に開けるファイルの上限を確認してください。
+
+`launchctl limit maxfiles`
+
+続いて、以下のコマンドを実行します(https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c より引用)。
+
+```
+#!/bin/sh
+
+# These are the original gist links, linking to my gists now.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+こちらはmacOSのCatalinaとMojaveで動作を確認しています。
+
 ## SIG Docsに参加する
 
 [コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。

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/)
 

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

content/en/docs/concepts/cluster-administration/addons.md

@@ -25,6 +25,7 @@ This page lists some of the available add-ons and links to their respective inst
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
 * [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](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.

content/en/docs/concepts/policy/resource-quotas.md

@@ -76,8 +76,7 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
-| `hugepages-<size>` | Across all pods in a non-terminal state, the number of
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. |
-huge page requests of the specified size cannot exceed this value. |
 | `cpu` | Same as `requests.cpu` |
 | `memory` | Same as `requests.memory` |
 
@@ -237,7 +236,7 @@ one value. For example:
           - middle
 ```
 
-If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
+If the `operator` is `Exists` or `DoesNotExist`, the `values` field must *NOT* be
 specified.
 
 ### Resource Quota Per PriorityClass

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -91,7 +91,7 @@ To see which admission plugins are enabled:
 kube-apiserver -h | grep enable-admission-plugins
 ```
 
-In 1.18, they are:
+In the current version, the default ones are:
 
 ```shell
 NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota

content/en/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -23,33 +23,33 @@ 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
+- User accounts are for humans. Service accounts are for processes, which run
-    run in pods.
+  in pods.
-  - User accounts are intended to be global. Names must be unique across all
+- User accounts are intended to be global. Names must be unique across all
-    namespaces of a cluster, future user resource will not be namespaced.
+  namespaces of a cluster. Service accounts are namespaced.
-    Service accounts are namespaced.
+- Typically, a cluster's user accounts might be synced from a corporate
-  - Typically, a cluster's User accounts might be synced from a corporate
+  database, where new user account creation requires special privileges and is
-    database, where new user account creation requires special privileges and
+  tied to complex business processes. Service account creation is intended to be
-    is tied to complex business processes. Service account creation is intended
+  more lightweight, allowing cluster users to create service accounts for
-    to be more lightweight, allowing cluster users to create service accounts for
+  specific tasks by following the principle of least privilege.
-    specific tasks (i.e. principle of least privilege).
+- Auditing considerations for humans and service accounts may differ.
-  - Auditing considerations for humans and service accounts may differ.
+- A config bundle for a complex system may include definition of various service
-  - 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
-    accounts for components of that system.  Because service accounts can be created
+  without many constraints and have namespaced names, such config is portable.
-    ad-hoc 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 `ServiceAccount` admission controller
-  - A Token controller
+- A Token controller
-  - A Service account 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:
 
@@ -66,56 +66,78 @@ When the `BoundServiceAccountTokenVolume` feature gate is enabled, the service a
 add a projected service account token volume instead of a secret volume. The service account token will expire after 1 hour by default or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
 
 This feature depends on the `RootCAConfigMap` feature gate enabled which publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver.
+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.
+
+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/).
 
 ### 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.
+- watches ServiceAccount creation and creates a corresponding
-- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets.
+  ServiceAccount token Secret to allow API access.
-- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed.
+- watches ServiceAccount deletion and deletes all corresponding ServiceAccount
-- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed.
+  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
+You must pass a service account private key file to the token controller in
-the `--service-account-private-key-file` option. The private key will be used to sign generated service account tokens.
+the `kube-controller-manager` using the `--service-account-private-key-file`
-Similarly, you must pass the corresponding public key to the kube-apiserver using the `--service-account-key-file`
+flag. The private key is used to sign generated service account tokens.
-option. The public key will be used to verify the tokens during authentication.
+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
+A controller loop ensures a Secret with an API token exists for each
-account. To create additional API tokens for a service account, create a secret
+ServiceAccount. To create additional API tokens for a ServiceAccount, create a
-of type `ServiceAccountToken` with an annotation referencing the service
+Secret of type `kubernetes.io/service-account-token` with an annotation
-account, and the controller will update it with a generated token:
+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
+```yaml
-{
+apiVersion: v1
-    "kind": "Secret",
+kind: Secret
-    "apiVersion": "v1",
+metadata:
-    "metadata": {
+  name: mysecretname
-        "name": "mysecretname",
+  annotations:
-        "annotations": {
+    kubernetes.io/service-account.name: myserviceaccount
-            "kubernetes.io/service-account.name": "myserviceaccount"
+type: kubernetes.io/service-account-token
-        }
-    },
-    "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
+
+A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
+ensures a ServiceAccount named "default" exists in every active namespace.
 
-Service Account Controller manages ServiceAccount inside namespaces, and ensures
-a ServiceAccount named "default" exists in every active namespace.

content/en/docs/setup/best-practices/cluster-large.md

@@ -2,126 +2,122 @@
 reviewers:
 - davidopp
 - lavalamp
-title: Building large clusters
+title: Considerations for large clusters
 weight: 20
 ---
 
-## Support
+A cluster is a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (physical
-
+or virtual machines) running Kubernetes agents, managed by the
-At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+Kubernetes {{< param "version" >}} supports clusters with up to 5000 nodes. More specifically,
+Kubernetes is designed to accommodate configurations that meet *all* of the following criteria:
 
+* No more than 100 pods per node
 * No more than 5000 nodes
 * No more than 150000 total pods
 * No more than 300000 total containers
-* No more than 100 pods per node
 
+You can scale your cluster by adding or removing nodes. The way you do this depends
+on how your cluster is deployed.
 
-## Setup
+## Cloud provider resource quotas {#quota-issues}
 
-A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
+To avoid running into cloud provider quota issues, when creating a cluster with many nodes,
-
+consider:
-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)).
+* Request a quota increase for cloud resources such as:
-
+    * Computer instances
-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.
-
-When setting up a large Kubernetes cluster, the following issues must be considered.
-
-### Quota Issues
-
-To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider:
-
-* Increase the quota for things like CPU, IPs, etc.
-  * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for:
     * CPUs
-    * VM instances
+    * Storage volumes
-    * Total persistent disk reserved
     * In-use IP addresses
-    * Firewall Rules
+    * Packet filtering rule sets
-    * Forwarding rules
+    * Number of load balancers
-    * Routes
+    * Network subnets
-    * Target pools
+    * Log streams
-* Gating the setup script so that it brings up new node VMs in smaller batches with waits in between, because some cloud providers rate limit the creation of VMs.
+* Gate the cluster scaling actions to brings up new nodes in batches, with a pause
+  between batches, because some cloud providers rate limit the creation of new instances.
 
-### Etcd storage
+## Control plane components
 
-To improve performance of large clusters, we store events in a separate dedicated etcd instance.
+For a large cluster, you need a control plane with sufficient compute and other
+resources.
 
-When creating a cluster, existing salt scripts:
+Typically you would run one or two control plane instances per failure zone,
+scaling those instances vertically first and then scaling horizontally after reaching
+the point of falling returns to (vertical) scale.
+
+You should run at least one instance per failure zone to provide fault-tolerance. Kubernetes
+nodes do not automatically steer traffic towards control-plane endpoints that are in the
+same failure zone; however, your cloud provider might have its own mechanisms to do this.
+
+For example, using a managed load balancer, you configure the load balancer to send traffic
+that originates from the kubelet and Pods in failure zone _A_, and direct that traffic only
+to the control plane hosts that are also in zone _A_. If a single control-plane host or
+endpoint failure zone _A_ goes offline, that means that all the control-plane traffic for
+nodes in zone _A_ is now being sent between zones. Running multiple control plane hosts in
+each zone makes that outcome less likely.
+
+### etcd storage
+
+To improve performance of large clusters, you can store Event objects in a separate
+dedicated etcd instance.
+
+When creating a cluster, you can (using custom tooling):
 
 * start and configure additional etcd instance
-* configure api-server to use it for storing events
+* configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events
 
-### Size of master and master components
+## Addon resources
 
-On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes
+Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/)
-in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are
+help to minimise the impact of memory leaks and other ways that pods and containers can
+impact on other components. These resource limits can and should apply to
+{{< glossary_tooltip text="addon" term_id="addons" >}} just as they apply to application
+workloads.
 
-* 1-5 nodes: n1-standard-1
+For example, you can set CPU and memory limits for a logging component:
-* 6-10 nodes: n1-standard-2
-* 11-100 nodes: n1-standard-4
-* 101-250 nodes: n1-standard-8
-* 251-500 nodes: n1-standard-16
-* more than 500 nodes: n1-standard-32
-
-And the sizes we use on AWS are
-
-* 1-5 nodes: m3.medium
-* 6-10 nodes: m3.large
-* 11-100 nodes: m3.xlarge
-* 101-250 nodes: m3.2xlarge
-* 251-500 nodes: c4.4xlarge
-* more than 500 nodes: c4.8xlarge
-
-{{< note >}}
-On Google Kubernetes Engine, the size of the master node adjusts automatically based on the size of your cluster. For more information, see [this blog post](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html).
-
-On AWS, master node sizes are currently set at cluster startup time and do not change, even if you later scale your cluster up or down by manually removing or adding nodes or using a cluster autoscaler.
-{{< /note >}}
-
-### Addon Resources
-
-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:
 
 ```yaml
+  ...
   containers:
   - name: fluentd-cloud-logging
-    image: k8s.gcr.io/fluentd-gcp:1.16
+    image: fluent/fluentd-kubernetes-daemonset:v1
     resources:
       limits:
         cpu: 100m
         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](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.
+Addons' default limits are typically based on data collected from experience running
+each addon on small or medium Kubernetes clusters. When running on large
+clusters, addons often consume more of some resources than their default limits.
+If a large cluster is deployed without adjusting these values, the addon(s)
+may continuously get killed because they keep hitting the memory limit.
+Alternatively, the addon may run but with poor performance due to CPU time
+slice restrictions.
 
-To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
+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):
+* Some addons scale vertically - there is one replica of the addon for the cluster
-  * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  or serving a whole failure zone. For these addons, increase requests and limits
-  * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  as you scale out your cluster.
-  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+* Many addons scale horizontally - you add capacity by running more pods - but with
-* 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):
+  a very large cluster you may also need to raise CPU or memory limits slightly.
-  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  The VerticalPodAutoscaler can run in _recommender_ mode to provide suggested
-* 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):
+  figures for requests and limits.
-  * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+* Some addons run as one copy per node, controlled by a {{< glossary_tooltip text="DaemonSet"
-  * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  term_id="daemonset" >}}: for example, a node-level log aggregator. Similar to
+  the case with horizontally-scaled addons, you may also need to raise CPU or memory
+  limits slightly.
 
-Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
+## {{% heading "whatsnext" %}}
-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
+`VerticalPodAutoscaler` is a custom resource that you can deploy into your cluster
-[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting).
+to help you manage resource requests and limits for pods.  
-
+Visit [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)
-### Allowing minor node failure at startup
+to learn more about `VerticalPodAutoscaler` and how you can use it to scale cluster
-
+components, including cluster-critical addons.
-For various reasons (see [#18969](https://github.com/kubernetes/kubernetes/issues/18969) for more details) running
-`kube-up.sh` with a very large `NUM_NODES` may fail due to a very small number of nodes not coming up properly.
-Currently you have two choices: restart the cluster (`kube-down.sh` and then `kube-up.sh` again), or before
-running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to whatever value you feel comfortable
-with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
-reason for the failure, those additional nodes may join later or the cluster may remain at a size of
-`NUM_NODES - ALLOWED_NOTREADY_NODES`.
 
+The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
+integrates with a number of cloud providers to help you run the right number of
+nodes for the level of resource demand in your cluster.

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]

content/en/docs/tasks/configure-pod-container/quality-service-pod.md

@@ -45,8 +45,8 @@ kubectl create namespace qos-example
 
 For a Pod to be given a QoS class of Guaranteed:
 
-* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
-* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
 
 Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
 memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -502,7 +502,14 @@ behavior:
     selectPolicy: Disabled
 ```
 
+## Implicit maintenance-mode deactivation
 
+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 
+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.
 
 ## {{% heading "whatsnext" %}}
 

content/en/docs/tutorials/stateful-application/zookeeper.md

@@ -26,7 +26,7 @@ Kubernetes concepts.
 -   [Pods](/docs/concepts/workloads/pods/)
 -   [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 -   [Headless Services](/docs/concepts/services-networking/service/#headless-services)
--   [PersistentVolumes](/docs/concepts/storage/volumes/)
+-   [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
 -   [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
 -   [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
@@ -522,7 +522,7 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
 ```
 
-This is the simplest possible way to safely log inside the container. 
+This is the simplest possible way to safely log inside the container.
 Because the applications write logs to standard out, Kubernetes will handle log rotation for you.
 Kubernetes also implements a sane retention policy that ensures application logs written to
 standard out and standard error do not exhaust local storage media.

content/id/docs/concepts/cluster-administration/logging.md

@@ -52,7 +52,7 @@ Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk
 
 ![Node-level _logging_](/images/docs/user-guide/logging/logging-node-level.png)
 
-Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam file dalam format json.
+Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam berkas dalam format json.
 
 {{< note >}}
 _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi.

content/id/docs/concepts/configuration/pod-priority-preemption.md

@@ -203,7 +203,7 @@ Misalnya sebuah Node N sedang dipertimbangkan untuk pemindahan Pod sehingga sebu
 *   Pod P dipertimbangkan untuk Node N.
 *   Pod Q sedang berjalan pada Node lain pada Zona yang sama dengan Node N.
 *   Pod P memiliki anti-afinitas yang berlaku pada seluruh Zona terhadap Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   Tidak ada kasus anti-afinitas lain antara Pod P dengan Pod-pod lainnya pada Zona tersebut.
 *   Untuk dapat menjadwalkan Pod P pada Node N, Pod Q dapat dipindahkan, tetapi
     Scheduler tidak melakukan pemindahan Pod antar Node. Jadi, Pod P akan

content/id/docs/concepts/configuration/secret.md

@@ -61,7 +61,7 @@ dan _password_ yang harus digunakan oleh Pod-Pod tersebut berada pada mesin loka
 dalam bentuk _file-file_ `./username.txt` dan `./password.txt`.
 
 ```shell
-# Buatlah file yang selanjutnya akan digunakan pada contoh-contoh selanjutnya
+# Buatlah berkas yang selanjutnya akan digunakan pada contoh-contoh selanjutnya
 echo -n 'admin' > ./username.txt
 echo -n '1f2d1e2e67df' > ./password.txt
 ```
@@ -271,7 +271,7 @@ dispesifikasikan di dalam sebuah _file_ `kustomization.yaml` di dalam sebuah dir
 
 Sebagai contoh, untuk menghasilan sebuah Secret dari _file-file_ `./username.txt` dan `./password.txt`
 ```shell
-# Membuat sebuah file kustomization.yaml dengan SecretGenerator
+# Membuat sebuah berkas kustomization.yaml dengan SecretGenerator
 cat <<EOF >./kustomization.yaml
 secretGenerator:
 - name: db-user-pass
@@ -310,7 +310,7 @@ username.txt:    5 bytes
 Sebagai contoh, untuk membuat sebuah Secret dari literal `username=admin` dan `password=secret`,
 kamu dapat menspesifikasikan _generator_ Secret pada _file_ `kustomization.yaml` sebagai
 ```shell
-# Membuat sebuah file kustomization.yaml dengan menggunakan SecretGenerator
+# Membuat sebuah berkas kustomization.yaml dengan menggunakan SecretGenerator
 $ cat <<EOF >./kustomization.yaml
 secretGenerator:
 - name: db-user-pass

content/id/docs/tasks/manage-kubernetes-objects/declarative-config.md

@@ -1,5 +1,5 @@
 ---
-title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi
+title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan Berkas Konfigurasi
 content_type: concept
 weight: 10
 ---
@@ -26,12 +26,12 @@ Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
 tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:
 
 - [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Berkas Konfigurasi Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
 
 Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
 dalam dokumen ini:
 
-- *objek file konfigurasi / file konfigurasi*: Sebuah *file* yang
+- *objek berkas konfigurasi / berkas konfigurasi*: Sebuah *file* yang
 mendefinisikan konfigurasi untuk sebuah objek Kubernetes. Dokumen ini akan memperlihatkan cara menggunakan *file* konfigurasi dengan perintah `kubectl apply`. *File-file* konfigurasi biasanya disimpan di sebuah *source control* seperti Git.
 - *konfigurasi objek live / konfigurasi live*: nilai konfigurasi *live* dari sebuah objek, sebagaimana yang tersimpan di klaster Kubernetes. Nilai-nilai ini disimpan di *storage* klaster Kubernetes, biasanya etcd.
 - *writer konfigurasi deklaratif / writer deklaratif*: Seseorang atau sebuah komponen perangkat lunak yang membuat pembaruan ke objek *live*. *Live writer* yang disebut pada dokumen ini adalah *writer* yang membuat perubahan terhadap *file* konfigurasi objek dan menjalankan perintah `kubectl apply` untuk menulis perubahan-perubahan tersebut.
@@ -340,7 +340,7 @@ Perintah `kubectl apply --prune` masih dalam versi alpha dan perubahan-perubahan
 Kamu harus berhati-hati ketika menggunakan perintah ini agar kamu tidak menghapus objek-objek lain secara tak sengaja.
 {{< /warning >}}
 
-Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah file konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.
+Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah berkas konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.
 
 {{< comment >}}
 TODO(pwittrock): Kita perlu mengubah cara kerja perintah ini untuk mencegah pengguna menjalankan apply ke sub direktori secara tidak disengaja.
@@ -372,7 +372,7 @@ Ketika memperbarui konfigurasi *live* dari sebuah objek, `kubectl apply` melakuk
 
 ### Perhitungan penggabungan *patch*
 
-Perintah `kubectl apply` menulis konten dari file konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:
+Perintah `kubectl apply` menulis konten dari berkas konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:
 
 1. Hitung *field-field* yang perlu dihapus. Ini mencakup *field-field* yang ada di `last-applied-configuration` tapi tidak ada di *file* konfigurasi.
 2. Hitung *field-field* yang perlu ditambah atau diubah. Ini mencakup *field-field* yang ada di *file* konfigurasi yang nilainya tidak sama dengan konfigurasi *live*.
@@ -533,7 +533,7 @@ Perlakukan *list* sama dengan *field* primitif. Ganti atau hapus keseluruhan lis
 # nilai last-applied-configuration*
     args: ["a", "b"]
 
-# nilai file konfigurasi
+# nilai berkas konfigurasi
     args: ["a", "c"]
 
 # nilai konfigurasi live
@@ -563,7 +563,7 @@ Strategi penggabungan ini menggunakan *tag* khusus `patchMergeKey` pada tiap *fi
     - name: nginx-helper-b # key: nginx-helper-b; akan dipertahankan pada hasil akhir
       image: helper:1.3
 
-# nilai file konfigurasi
+# nilai berkas konfigurasi
     containers:
     - name: nginx
       image: nginx:1.10
@@ -625,7 +625,7 @@ TODO(pwittrock): *Uncomment* ini untuk versi 1.6
 
 *API server* mengisi *field* tertentu dengan nilai *default* pada konfigurasi *live* jika nilai *field-field* tersebut tidak dispesifikasikan ketika objek dibuat.
 
-Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. File berikut tidak menspesifikasikan `strategy`:
+Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. Berkas berikut tidak menspesifikasikan `strategy`:
 
 {{< codenew file="application/simple_deployment.yaml" >}}
 
@@ -700,7 +700,7 @@ spec:
         ports:
         - containerPort: 80
 
-# file konfigurasi
+# berkas konfigurasi
 spec:
   strategy:
     type: Recreate # nilai yang diperbarui
@@ -863,7 +863,7 @@ template:
 ## {{% heading "whatsnext" %}}
 
 - [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan Berkas Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 

content/id/docs/tasks/manage-kubernetes-objects/imperative-command.md

@@ -120,7 +120,7 @@ kubectl create --edit -f /tmp/srv.yaml
 ```
 
 1. Perintah `kubectl create service` membuat konfigurasi untuk objek Service dan menyimpannya di `/tmp/srv.yaml`.
-1. Perintah `kubectl create --edit` membuka file konfigurasi untuk diedit sebelum objek dibuat.
+1. Perintah `kubectl create --edit` membuka berkas konfigurasi untuk disunting sebelum objek dibuat.
 
 
 

content/it/training/_index.html

@@ -112,7 +112,6 @@ class: training
     </center>
   </div>
   <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
   </div>
 </div>

content/ja/_index.html

@@ -41,12 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">2020年8月17日-20日のKubeCon EUバーチャルに参加する</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">2020年11月17日-20日のKubeCon NAバーチャルに参加する</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">2021年5月4日-7日のKubeCon EUバーチャルに参加する</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

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
+  - 所在地: カリフォルニア州サンフランシスコ
+  - 業界: ソフトウェア
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/appdirect/banner1.jpg')">
+<h2>課題</h2>
-<h1>ケーススタディ：<img src="/images/appdirect_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;font-size:0.5em">AppDirect：AppDirectはいかにしてKubernetessを活用し、エンジニアリングスタッフが10倍になるほどの成長を後押ししたのか<br>
 
-</div></h1>
+<p><a href="https://www.appdirect.com/">AppDirect</a> はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。そのため、提供までのパイプラインにボトルネックがあったのです。」これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">企業名 &nbsp;<b>AppDirect</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地&nbsp; <b>カリフォルニア州サンフランシスコ</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界&nbsp;<b>ソフトウェア</b>
+<p>Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a> モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターを<a href="https://aws.amazon.com/">AWS</a> 上や世界中のオンプレミス環境で展開しています。</p>
-</div>
 
-<hr>
+<h2>インパクト</h2>
-<section class="section1">
+
-<div class="cols">
+<p>Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに<a href="https://www.atlassian.com/software/jira">Jira</a> のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。</p>
-  <div class="col1" style="width:100%">
+
-    <h2>課題</h2><a href="https://www.appdirect.com/">AppDirect</a> はクラウドベースの製品やサービス向けにエンドツーエンドのeコマースプラットフォームを提供しています。2014年、ソフトウェア開発ディレクターであるPierre-Alexandre LacerteがAppDirectで働き始めた時、同社は「Tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑になっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、それから別のチームがその変更を取り込むといった具合です。
+{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}}
-そのため、提供までのパイプラインにボトルネックがあったのです。」
+「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」
-これと同時に、エンジニアリングチームが大きくなっていき、その成長を後押しし加速する上でも、より良いインフラが必要であることに同社は気づいたのです。
+{{< /case-studies/quote >}}
-<br><br><h2>ソリューション</h2>Lacerteは言います。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろうぜ、というものです。そうすれば彼らも『そうだね、モノリスはもう建てたくないしサービスを構築したいよ』と言うでしょう。」
+
-彼らは、2016年初め<a href="https://kubernetes.io/">Kubernetes</a> の採用を決定するにあたり、他のいくつかの技術を調査・検討し、プロトタイプを作りました。 Lacerteのチームはこのプラットフォームへの監視のために<a href="https://prometheus.io/">Prometheus</a>
+{{< case-studies/lead >}}
-モニタリングツールを統合しました。この次にあるのはトレーシングです。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターを<a href="https://aws.amazon.com/">AWS</a> 上や世界中のオンプレミス環境で展開しています。 <br><br><h2>インパクト</h2>Kubernetesプラットフォームは、エンジニアリングチームのここ数年の10倍成長を後押ししてきました。
+<a href="https://www.appdirect.com/">AppDirect</a> は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。
-彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います」と、Lacerte氏は述べています。Kubernetesとサービス化へ移行していくことは、SCPコマンドを用いた、カスタムメイドで不安定なシェルスクリプトへの依存性を弱め、非常に高速になったことを意味していました。
+{{< /case-studies/lead >}}
-新しいバージョンをデプロイする時間は4時間から数分間に短縮されました。
+
-こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに<a href="https://www.atlassian.com/software/jira">Jira</a> のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerte氏は言います。
+<p>2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」</p>
-以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
+
-また、同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現できました。
+<p>これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、<a href="https://nodejs.org/">Node.js</a> に <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>といった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。</p>
-</div>
+
-</div>
+{{< case-studies/quote 
-</section>
+  image="/images/case-studies/appdirect/banner3.jpg"
-<div class="banner2">
+  author="AppDirect ソフトウェア開発者　Alexandre Gervais"
-  <div class="banner2text">「計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
+>}}
-</div>
+「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」
-<section class="section2">
+{{< /case-studies/quote >}}
-<div class="fullcol">
+
-  <h2><a href="https://www.appdirect.com/">AppDirect</a> は2009年以来、クラウドベースの製品やサービス向けのエンドツーエンドのeコマースプラットフォームによって、ComcastやGoDaddyといった組織がデジタルサプライチェーンをシンプルにすることに役立ってきました。</h2><br> 2014年にソフトウェア開発ディレクターのPierre-Alexandre Lacerteが働き始めたとき、AppDirectでは「tomcatベースのインフラにモノリシックなアプリケーションをデプロイしていて、リリースプロセス全体が必要以上に複雑なものとなっていました」と彼は振り返ります。「たくさんのマニュアルステップがありました。1人のエンジニアがある機能を構築し、Pull requestを作成、そしてQAもしくは別のエンジニアの手によってその機能を検証する、といった具合でした。さらにこれがマージされれば、また別の誰かがデプロイ作業の面倒をみることになるでしょう。そのため、提供までのパイプラインにボトルネックがいくつもありました。」<br><br> これと同時に、40人のエンジニアリングチームが大きくなっていくにつれ、その成長を後押しし加速する上でも、より良いインフラが必要となってくることに同社は気づいたのです。そのころプラットフォーム チームの一員であったLacerteには、<a href="https://nodejs.org/">Node.js</a> に <a href="http://spring.io/projects/spring-boot">Spring Boot Java</a>といった、異なるフレームワークや言語を使いたいといった声が複数のチームから聞こえてくるようになってきました。同社の成長とスピードを両立するには、(チームが自律的に動き、自らがデプロイし、稼働中のサービスに責任を持てるような)よりよいインフラやシステムがこの会社には必要だということに彼はすぐに気づいたのです。</div>
+<p>Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。</p>
-</section>
+
-<div class="banner3" style="background-image: url('/images/case-studies/appdirect/banner3.jpg')">
+<p>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。</p>
-  <div class="banner3text">「正しいタイミングで正しい判断ができました。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発者　Alexandre Gervais </span></div>
+
-</div>
+<p>今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。</p>
-<section class="section3">
+
-<div class="fullcol">Lacerteは当初から言っていました。「私のアイデアは、チームがサービスをもっと高速にデプロイできる環境を作ろう、というものです。そうすれば彼らもこう言うでしょう『そうだよ、モノリスを建てるなんてもうしたくないしサービスを構築したいんだ』と」(Lacerteは2019年に同社を退社)。<br><br>Lacerteのグループは運用チームと連携することで同社の <a href="https://aws.amazon.com/">AWSのインフラ</a>により多くアクセスし、コントロールするようになりました。そして、いくつかのオーケストレーション技術のプロトタイプを作り始めたのです。「当時を振り返ると、Kubernetesはちょっとアンダーグラウンドというか、それほど知られていなかったように思います。」と彼は言います。「しかし、コミュニティやPull requestの数、GitHub上でのスピードなどをよく見てみると勢いが増してきていることがわかりました。他の技術よりも管理がはるかに簡単であることもわかりました。」彼らは、Kubernetes上で <a href="https://www.chef.io/">Chef</a> や<a href="https://www.terraform.io/">Terraform</a> によるプロビジョニングを用いながら最初のいくつかのサービスを開発しました。その後さらにサービスも、自動化されるところも増えました。「韓国、オーストラリア、ドイツ、そしてアメリカ、私たちのクラスターは世界中にあります。」とLacerteは言います。「自動化は私たちにとって極めて重要です。」今彼らは大部分で<a href="https://github.com/kubernetes/kops">Kops</a>を使っていて、いくつかのクラウドプロバイダーから提供されるマネージドKubernetesサービスも視野に入れていれています。<br><br> 今もモノリスは存在してはいますが、コミットや機能はどんどん少なくなってきています。あらゆるチームがこの新たなインフラ上でデプロイしていて、それらはサービスとして提供されるのが一般的です。今やAppDirectは本番環境で50以上のマイクロサービス、15のKubernetesクラスターをAWS上や世界中のオンプレミス環境で展開しています。<br><br> Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。
+<p>Kubernetesプラットフォームがデプロイ時間に非常に大きなインパクトを与えたことから、Lacerteの戦略が究極的に機能しました。カスタムメイドで不安定だった、SCPコマンドを用いたシェルスクリプトに対する依存性を弱めることで、新しいバージョンをデプロイする時間は4時間から数分にまで短縮されるようになったのです。こういったことに加え同社は、開発者たちが自らのサービスとして仕立て上げるよう、数多くの努力をしてきました。「新しいサービスを始めるのに、 <a href="https://www.atlassian.com/software/jira">Jira</a>のチケットや他のチームとのミーティングはもはや必要ないのです」とLacerteは言います。以前、週あたり1〜30だった同社のデプロイ数は、いまや週1,600デプロイにまでなっています。</p>
-</div>
+
-</section>
+{{< case-studies/quote 
-<div class="banner4" style="background-image: url('/images/case-studies/appdirect/banner4.jpg');width:100%;">
+  image="/images/case-studies/appdirect/banner4.jpg"
-  <div class="banner4text">「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
+  author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte"
-</div>
+>}}
+「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」
+{{< /case-studies/quote >}}
 
 <section class="section5" style="padding:0px !important">
 
-<div class="fullcol">さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました<br><br>AppDirectのクラウドネイティブなスタックには<a href="https://grpc.io/">gRPC</a>、<a href="https://www.fluentd.org/">Fluentd</a>も含まれていて、そして今このチームは<a href="https://opencensus.io/">OpenCensus</a>の立ち上げに取り組んでいるところです。このプラットフォームはすでに<a href="https://prometheus.io/">Prometheus</a> で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境では<a href="https://slack.com/">Slack</a> メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」</div>
+<p>さらに、Kubernetesプラットフォームは、エンジニアリングチームがこの数年で10倍も拡大したことを後押してきたともいえます。「AppDirectのコアバリューの1つとして掲げている『Ownership』には、モノリシックなコードベースに依存しないでサービス提供ができる、当社の能力が反映されていると思います。」とLacerteとこの取り組みに参加したソフトウェア開発者のAlexandre Gervaisは述べています。「いまや小さなチームでも当社のビジネスドメインモデルの非常に重要な部分を所有(own)しています。彼らは、コードベース全体についての知識は限られていますが、専門領域として切り離された形でチームをオペレーションしているのです。こういったやり方が、複雑性を緩和することに繋がっています。」彼らが継続的に機能追加しているという事実と相まって「この新たなインフラがなければ、我々は大幅なスローダウンを強いられていたと思います。」と、Lacerte氏は述べています。同社はビジネスアワーにおけるトラフィックの増加に応じ、自社のマーケットプレイスや課金周りのモノリシックだったシステムを従来のEC2ホストからKubernetesに移し、オートスケール機能を活用することと併せてコスト削減を実現することもできました</p>
 
-<div class="banner5" >
+<p>AppDirectのクラウドネイティブなスタックには<a href="https://grpc.io/">gRPC</a>、<a href="https://www.fluentd.org/">Fluentd</a>も含まれていて、そして今このチームは<a href="https://opencensus.io/">OpenCensus</a>の立ち上げに取り組んでいるところです。このプラットフォームはすでに<a href="https://prometheus.io/">Prometheus</a> で統合させているので、「どこかのチームがなんらかのサービスをデプロイするときには、通知、アラートやコンフィグ情報を受け取ることになります」とLacerteは言います。「たとえば、テスト環境ではSlackでメッセージが受け取れればいいですが、本番環境では<a href="https://slack.com/">Slack</a> メッセージと併せ呼び出しもしてもらいたいです。なので私たちはPagerDutyとのインテグレーションも行っています。サービスにおけるチームのオーナーシップが増していっているのです。」</p>
-  <div class="banner5text">「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte</span></div>
-</div>
 
-<div class="fullcol">もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」 <br><br> エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」<br><br>Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」</div>
+{{< case-studies/quote author="AppDirect ソフトウェア開発 ディレクター Pierre-Alexandre Lacerte" >}}
-</section>
+「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務に移行しました。機能や設定のデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」
+{{< /case-studies/quote >}}
+
+<p>もちろんそれは、より多くの責任も意味しています。「私たちはエンジニアに視野を広げるように依頼しました」とGervaisは言います。「私たちは、『ブランチにコードをプッシュする』だけのカルチャーから、コードベースを越えた、刺激的な新しい責務へ移行しました。機能やコンフィグのデプロイ、アプリケーションとビジネスメトリクスのモニタリング、そして機能停止が起きた場合の電話サポートなどがそれにあたります。「それは計り知れないほどのエンジニアリング文化のシフトでしたが、規模とスピードを考えるとそのメリットは否定できません。」</p>
+
+<p>エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」</p>
+
+<p>Kubernetesの3年半もの旅を振り返り、GervaisはAppDirectが「正しいタイミングで正しい判断ができた」と感じています。「Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。スケールアウトしていく中で直面する新たな難題に取り組むにはどこに注力すべきか、私たちはわかっています。このコミュニティはとても活発で、当社の優秀なチームをすばらしく補完してくれています。前進していくために私たちが注力すべきなのは、エコシステムから恩恵を受けながら、日々のオペレーションにビジネス的な付加価値を提供していくことでしょう。」</p>

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
+featured: false
-logo: chinaunicom_featured_logo.png
+
-featured: true
+new_case_study_styles: true
-weight: 1
+heading_background: /images/case-studies/chinaunicom/banner1.jpg
-quote: >
+heading_title_logo: /images/chinaunicom_logo.png
-   Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。
+title_prefix: "ケーススタディ："
+subheading: >
+  Kubernetesが私たちのクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。
+case_study_details:
+  - 企業名: China Unicom
+  - 所在地: 中国、北京
+  - 業界: テレコム
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/chinaunicom/banner1.jpg')">
+<h2>課題</h2>
-<h1>ケーススタディ：<img src="/images/chinaunicom_logo.png" class="header_logo" style="width:25%;margin-bottom:-1%"><br> <div class="subhead" style="margin-top:1%;line-height:1.4em">China Unicom社：KubernetesによるITコスト削減と効率性向上をいかにして実現したか<br>
 
-</div></h1>
+<p>China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 <a href="https://www.vmware.com/">VMWare</a>、<a href="https://www.openstack.org/">OpenStack</a>のインフラや<a href="https://rancher.com/">Docker</a>によるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">
+<p>急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。</p>
-        企業名 &nbsp;<b>China Unicom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 <b>中国、北京</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界<b>&nbsp;テレコム</b>
-</div>
 
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>課題</h2>
-    China Unicomは、中国でトップ3の通信事業者の1つであり、その3億人のユーザーにサービスを提供するために、2016年以来 <a href="https://www.vmware.com/">VMWare</a>、<a href="https://www.openstack.org/">OpenStack</a>のインフラや<a href="https://rancher.com/">Docker</a>によるコンテナ化を用い数千のサーバーのデータセンターを複数運用しています。残念なことに、「リソース使用率は相対的に低かった」と、プラットフォーム技術のR&amp;D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションに収容できるクラウドプラットフォームがありませんでした。」以前は完全な国有企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、いまや商用製品ではなくオープンソース技術を活用した社内開発にも注力しています。そこで、ZhangのChina Unicomの研究開発チームは、クラウドインフラ用のオープンソースオーケストレーションツールを探索し始めたのです。
-<br><br>
-
-    <h2>ソリューション</h2>
-    急成長し、オープンソースコミュニティも成熟しているKubernetesはChina Unicomにとって自然な選択となりました。同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。「Kubernetesが私たちのクラウドインフラの経験値を上げてくれました」とZhangはいいます。「今のところ、これに代わる技術はありません。」また、China Unicomはそのマイクロサービスフレームワークのために、<a href="https://istio.io/">Istio</a>、 <a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://coredns.io/">CoreDNS</a>、そして<a href="https://www.fluentd.org/">Fluentd</a>も活用しています。
-<br><br>
 <h2>インパクト</h2>
-    KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。
-リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。
 
-</div>
+<p>KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たった5人で保守されているのです。これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。</p>
 
-</div>
+{{< case-studies/quote author="Chengyu Zhang、China Unicom プラットフォーム技術R&D グループリーダー" >}}
-</section>
+「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」
-<div class="banner2">
+{{< /case-studies/quote >}}
-  <div class="banner2text">
-        「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。今のところ、これに代わる技術はありません。」
-<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang、 China Unicom プラットフォーム技術R&amp;D グループリーダー</span></span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。 </h2>
 
-    その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&amp;D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」
+{{< case-studies/lead >}}
- <br><br>
+China Unicomは、3億人を超えるユーザーを抱える、中国国内でトップ3の通信事業者の1つです。
-  そこで新しい技術、研究開発(R&amp;D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。
+{{< /case-studies/lead >}}
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/chinaunicom/banner3.jpg');width:100%;padding-left:0;">
-  <div class="banner3text">
-        「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」<span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Chengyu Zhang、 China Unicom プラットフォーム技術R&amp;D グループリーダー</span></span>
 
-  </div>
+<p>その舞台裏で、同社は2016年以来、Dockerコンテナ、VMware、OpenStackインフラなどを用いて、数千のサーバーを持つデータセンターを複数運用しています。残念ながら、「リソース利用率は相対的に低かった」と、プラットフォーム技術のR&D部門のグループリーダーであるChengyu Zhangは語っています。「そして、私たちには何百ものアプリケーションを収容できるクラウドプラットフォームがありませんでした。」</p>
-</div>
-<section class="section3">
-<div class="fullcol">
-      China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。<br><br>
 
-  同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。<br><br>
+<p>そこで新しい技術、研究開発(R&D)、およびプラットフォームの責務を担うZhangのチームは、IT管理におけるソリューションの探索を始めました。以前は完全な国営企業だったChina Unicomは、近年BAT(Baidu、Alibaba、Tencent)およびJD.comからの民間投資を受け、今は商用製品ではなくオープンソース技術を活用した社内開発に注力するようになりました。こういったこともあり、Zhangのチームはクラウドインフラのオープンソースオーケストレーションツールを探し始めたのです。</p>
 
-  「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」
+{{< case-studies/quote
+  image="/images/case-studies/chinaunicom/banner3.jpg"
+  author="Chengyu Zhang、 China Unicom プラットフォーム技術R&D グループリーダー"
+>}}
+「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
+{{< /case-studies/quote >}}
 
-</div>
+<p>China Unicomはすでにコアとなる事業運用システムにMesosを活用していましたが、チームにとっては新しいクラウドプラットフォームにはKubernetesの選択が自然だろうと感じられたのです。「大きな理由は、Kubernetesには成熟したコミュニティがある、ということでした」とZhangは言います。「さらにKubernetesは非常に早いペースで成長していることもあり、さまざまな人のベストプラクティスから多くを学ぶことができるのです。」 またChina UnicomはマイクロサービスフレームワークのためにIstio、Envoy、CoreDNS、およびFluentdも使用しています。</p>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/chinaunicom/banner4.jpg');width:100%">
-  <div class="banner4text">
-    「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Jie Jia、China Unicom プラットフォーム技術 R&amp;D</span>
-  </div>
-</div>
 
-<section class="section5" style="padding:0px !important">
+<p>同社のKubernetes対応クラウドプラットフォームでは、現状の50のマイクロサービスに加え、これから新たに開発されるすべてをここでホストしていくそうです。China Unicomの開発者たちは自身の手による開発を省き、APIを介すことで簡単に技術が利用できるようになりました。このクラウドプラットフォームは、同社データセンタのPaaSプラットフォームに繋がった20〜30のサービスを提供することに加え、中国国内の31省にわたる拠点の社内ユーザーたちが行うビッグデータ分析などもサポートしています。</p>
-<div class="fullcol">
-    事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」<br><br>
-  China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。
-</div>
 
-<div class="banner5" >
+<p>「Kubernetesが私達のクラウドインフラの経験値を上げてくれました。」とZhangはいいます。「今のところ、これに代わる技術はありません。」</p>
-  <div class="banner5text">
-「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Jie Jia、China Unicom プラットフォーム技術 R&amp;D</span></div>
-</div>
 
-<div class="fullcol">
+{{< case-studies/quote 
-    プラットフォーム技術 R&amp;D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。<br><br>
+  image="/images/case-studies/chinaunicom/banner4.jpg"
-  「企業は  <a href="https://rancher.com/">Rancher</a>  のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」 <br><br>
+  author="Jie Jia、China Unicom プラットフォーム技術 R&D"
+>}}
+「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います。」
+{{< /case-studies/quote >}}
 
-  今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの<a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)</a>に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。<br><br>
+<p>事実として、KubernetesはChina Unicomの運用と開発、両方について効率を高めてくれました。リソース使用率は20〜50％上がり、ITインフラのコストも削減され、数時間かかっていたデプロイ時間は5〜10分にまで短縮されました。「こうすることができたのはおもに自己修復機能(self-healing)とスケーラビリティによるもので、これらによって私たちの運用や保守の効率を向上させることができるのです」とZhangは言います。「たとえば、私たちのシステムは今たったの5人で保守されているのです。」</p>
 
-  それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」
+<p>China UnicomにおけるKubernetesでの成功体験から、Zhangと彼のチームはコミュニティに積極的に貢献するようになりました。それは、Meetupやカンファレンスに参加したり、同じ道のりを歩むことを検討している他の企業にアドバイスを提供したりすることから始まりました。「とくに、トラディショナルなクラウドコンピューティング システムを保有してきた企業には、クラウドネイティブコンピューティングのコミュニティに参加することを本当にお勧めします」とZhangは言います。</p>
 
-</div>
+{{< case-studies/quote author="Jie Jia、China Unicom プラットフォーム技術 R&D" >}}
-</section>
+「企業はRancherのような事業者が提供するマネージドサービスを活用することができます。こうした技術はすでにカスタマイズされて提供されるので、簡単に利用することができるでしょう。」
-</body>
+{{< /case-studies/quote >}}
-</html>
+
+<p>プラットフォーム技術 R&D チームの一員であるJie Jiaは、「この技術は比較的複雑ですが、開発者が慣れれば、恩恵をすべて享受できるのではないかと思います」と付け加えています。一方でZhangは、仮想マシンベースのクラウドでの経験から見ると、「Kubernetesとこれらのクラウドネイティブ技術は比較的シンプルなのではないか」と指摘しています。</p>
+
+<p>「企業は  <a href="https://rancher.com/">Rancher</a>  のような事業者が提供するマネージドサービスを活用することができます。こうした技術はカスタマイズされて提供されるので、簡単に利用することができるでしょう。」</p>
+
+<p>今後China Unicomはビッグデータと機械学習に重点を置いて、Kubernetes上でより多くのアプリケーションを開発することを計画しています。彼らのチームは築き上げたクラウドプラットフォームを継続的に最適化しており、CNCFの<a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">認定Kubernetesコンフォーマンスプログラム(Certified Kubernetes Conformance Program)</a>に参加するべく、そのための適合テスト(Conformance test)への合格を目指しています。また彼らは、どこかのタイミングでコミュニティにコードをコントリビューションすることも目指しています。</p>
+
+<p>それが意欲的な発言と聞こえるのは、彼らがKubernetesを採用することで得た結果が彼らの期待していた最大値をも超えていたからでしょう。Zhangは次のように言います。「これほどの短期間でここまでのスケーラビリティを達成できるとは思いもよりませんでした。」</p>

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
+featured: false
-logo: nav_featured_logo.png
-featured: true
-weight: 3
 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
+  - 所在地: ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ
+  - 業界: 事業者向け金融サービス
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/nav/banner1.jpg')">
+<h2>課題</h2>
-  <h1>ケーススタディ：<img src="/images/nav_logo.png" class="header_logo" style="width:15%"><br><div class="subhead" style="margin-top:1%">スタートアップはどのようにしてKubernetesでインフラコストを50％も削減したのか</div></h1>
 
-</div>
+<p>2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」</p>
 
-<div class="details">
-	企業名 &nbsp;<b>Nav</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>ユタ州ソルトレイクシティ、カリフォルニア州サンマテオ</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>事業者向け金融サービス</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%;margin-left:-1.5%">
-<br><br>
- <h2>課題</h2>
-2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。このスタートアップは5年で急速に成長したことで、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」とエンジニアリングディレクターのTravis Jeppsonは述べています。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、同じリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました。」
-  <br><br>
 <h2>ソリューション</h2> 
-数多くのオーケストレーション ソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>上で稼働する <a href="https://kubernetes.io/">Kubernetes</a>を採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
+
+<p>数多くのオーケストレーション ソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>上で稼働する <a href="https://kubernetes.io/">Kubernetes</a>を採用することを決めました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」</p>
 
 <h2>インパクト</h2>
-4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。
 
-</div>
+<p>4人編成のチームは、6か月でKubernetesを稼働させ、その後の6ヶ月でNavの25あったマイクロサービスすべてのマイグレーションを完了させました。その結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は5倍増えました。そして同社はインフラコストを50％削減しています。</p>
-</div>
-</section>
 
-<div class="banner2">
+{{< case-studies/quote author="Travis Jeppson、Nav  エンジニアリング ディレクター" >}}
-  <div class="banner2text"><iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> 
+<iframe width="500" height="320" src="https://www.youtube.com/embed/0IbOk1_H-f0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
-
+<br>
-<br><br> 
 「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。さらにその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」
- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav  エンジニアリング ディレクター</span></div>
+{{< /case-studies/quote >}}
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。 </h2>
-数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」
-<br><br>
- こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」
 
-</div>
+{{< case-studies/lead >}}
-</section>
+2012年に設立された <a href="https://www.nav.com/">Nav</a>は、小規模事業者たちに、民間信用調査企業主要3社 —Equifax、Experian、Dun＆Bradstreet— におけるビジネス信用スコアと、彼らのニーズに最適な資金調達オプションを提供しています。「スモールビジネスの成功率を上げていくこと。」そのミッションはここに凝縮される、とエンジニアリングディレクターのTravis Jeppsonは言います。
-<div class="banner3" style="background-image: url('/images/case-studies/nav/banner3.jpg')">
+{{< /case-studies/lead >}}
-  <div class="banner3text"> 「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Travis Jeppson、Nav エンジニアリングディレクター</span></div>
 
+<p>数年前、Navは自分たちの成功への道筋に、障害があることを認識しました。ビジネスが急速に成長し、「クラウド環境が非常に大きくなっていったのですが、これらの環境の使用率は極端に低く、1％を下回っていました」と、Jeppsonは言います。「問題の大部分はスケールに関するものでした。私たちはそこにただお金を投入しようとしていました。『もっと多くのサーバーを稼働させよう。増えた負荷をさばくためにより多く作業しよう』といった具合に。私たちはスタートアップなので、そんなことをしていては終焉の一途をたどりかねませんし、そんなことにに使えるほどお金の余裕は我々にはないのです。」</p>
 
-</div>
+<p>こういったことに加えてすべての新サービスは違う10人を経由してリリースされなければならず、サービス立ち上げに2週間という受け入れがたいほどの時間をかけていたのです。パッチ管理とサーバ管理のすべてが手動で行われていたので、皆がそれらを見守り、うまく維持していく必要があったのです」とJeppsonは付け加えます。「非常にやっかいなシステムでした。」</p>
-<section class="section3">
-<div class="fullcol">Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。<br><br>
- 数多くのオーケストレーションソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>での<a href="https://kubernetes.io/">Kubernetes</a> 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」<br><br>
- Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために <a href="http://kubespray.io/">Kubespray</a> を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nav/banner4.jpg')" style="width:100%">
-  <div class="banner4text">
-「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav エンジニアリングディレクター</span>
- </div>
-</div>
 
-<section class="section5" style="padding:0px !important">
+{{< case-studies/quote
+  image="/images/case-studies/nav/banner3.jpg"
+  author="Travis Jeppson、Nav エンジニアリングディレクター"
+>}}
+「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています。」
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
+<p>Jeppsonは前職でコンテナを取り扱っていたため、Navの経営陣にこれらの問題の解決策としてこの技術を売り込みました。そして2017年初め彼の提案にゴーサインがでました。「クラウド環境の使用率と実際私たちに必要なものとを連動させたかったので、類似したリソースプールを共有しながら複数のワークロードそれぞれを分離して実行できるコンテナ化やオーケストレーションを検討しました」と、彼は言います。</p>
-この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。
-そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために <a href="https://gitlab.com/">GitLab</a>にリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>を用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」<br><br>
- マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。<br><br>
- また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、<a href="https://www.twistlock.com/">Twistlock</a>ツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。
-</div>
 
-<div class="banner5" >
+<p>数多くのオーケストレーションソリューションを評価した結果、Navチームは <a href="https://aws.amazon.com/">AWS</a>での<a href="https://kubernetes.io/">Kubernetes</a> 採用を決断しました。Kubernetesを取り巻くコミュニティの強みは人を引きつける点にあり、それがGoogleから生まれたものであることもその一つです。加えて、「他のソリューションは、かなり手間がかかり、本当に複雑で大きなものでした。そしてすぐに管理できるかという点においても厳しいものになりがちでした」とJeppsonは言います。「Kubernetesはその当時の私たちのニーズに合ったオーケストレーションソリューションに踏み出せる、とてもシンプルなやり方を提供してくれました。一方でその拡張性は、私たちがKubernetesと共に成長し、その後の追加機能を組み入れることを可能にしてくれました。」</p>
-  <div class="banner5text">「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Travis Jeppson、Nav  エンジニアリング ディレクター</span></div>
-</div>
 
-<div class="fullcol">
+<p>Jeppsonの4人編成のエンジニアリングサービスチームは、Kubernetesを立ち上げ、稼働させるのに6ヶ月かけました（クラスターを動かすために <a href="http://kubespray.io/">Kubespray</a> を使いました）。そして、その後6ヶ月かけNavの25のマイクロサービスと一つのモノリシックな主要サービスのフルマイグレーションを完了させました。「すべて書き換えたり、止めることはできませんでした」と彼は言います。「稼働し、利用可能であり続けなければいけなかったですし、ダウンタイムがあってもをそれを最小にしなければなりませんでした。そのためパイプライン作成、メトリクスやロギングといったことについてよくわかるようになりました。さらにKubernetes自身についても習熟し、起動、アップグレード、サービス提供の仕方についてもわかるようになりました。そうして移行を少しずつ進めていきました。」</p>
- Kubernetesが導入された中、Navチームは <a href="https://prometheus.io/">Prometheus</a>を採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」<br><br>
- これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らは<a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://opentracing.io/">OpenTracing</a>、そして <a href="https://www.jaegertracing.io/">Jaeger</a>を検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」<br><br>
- もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」
 
-</div>
+{{< case-studies/quote
-</section>
+  image="/images/case-studies/nav/banner4.jpg"
+  author="Travis Jeppson、Nav エンジニアリングディレクター"
+>}}
+「Kubernetesは、これまで経験したことのない新たな自由とたくさんの価値をNavにもたらしてくれました。」
+{{< /case-studies/quote >}}
+
+<p>この過程で重要だったのは、Navの50人のエンジニアを教育すること、そしてマイグレーションに当たり新たなワークフローやロードマップについて透明性を確保することでした。そこでJeppsonはエンジニアリングスタッフ全員に対し定期的なプレゼンテーションや、一週間にわたる1日4時間の実習の場を設けました。そして彼はすべての情報を置いておくために <a href="https://gitlab.com/">GitLab</a>にリポジトリを作成しました。 「フロントエンドとバックエンドの開発者たち全員に、<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/">kubectl</a>を用い、独力でnamespaceを作成し、取り扱う方法を見せていきました」と彼は言います。「いまや、彼らはやってきて『これは準備OKだ』というだけで済むことが多くなりました。GitLabの小さなボタンをクリックすれば本番環境にリリースできるようになっているので彼らはすぐに次の行動に移ることができます。」</p>
+
+<p>マイグレーションが2018年初めに完了したあとの結果は目覚しいものでした。導入のきっかけとなったリソース使用率については、1％から40％まで増加しました。かつて新しいサービスを立ち上げるのに2人の開発者が2週間かけていましたが、いまや開発者はたった一人で10分もかかりません。デプロイ数は1日あたり10だったものから50となり5倍増えました。そして同社はインフラコストを50％削減しています。「次はデータベース側に取り組みたいです。それができればかなりのコスト削減を継続できるでしょう」とJeppsonは言います。</p>
+
+<p>また、KubernetesはNavのコンプライアンスのニーズにも力を貸しました。以前は、「1つのアプリケーションを1つのサーバーにマッピングする必要がありました。これは主にデータ周辺でコンプライアンスの異なるレギュレーションがあったためです」とJeppsonは言います。「KubernetesのAPIを用いれば、ネットワークポリシーを追加し、必要に応じてそれらのデータを分離し制限をかけることができるようになります。」同社は、クラスターを規制のないゾーンと、独自ノードセットを持ったデータ保護を行うべき規制ゾーンに分離しています。また、<a href="https://www.twistlock.com/">Twistlock</a>ツールを使用することでセキュリティを確保しています。「夜、よく眠れることもね」と彼は付け加えます。</p>
+
+{{< case-studies/quote author="Travis Jeppson、Nav  エンジニアリング ディレクター" >}}
+「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」
+{{< /case-studies/quote >}}
+
+<p>Kubernetesが導入された中、Navチームは <a href="https://prometheus.io/">Prometheus</a>を採用してシステムのメトリクスやロギングの改良も始めました。。「Prometheusは開発者にとって、とても採用しやすいメトリクスの標準を作ってくれました」とJeppsonは言います。「彼らには、何をしたいかを示し、したいことを実践し、そして彼らのコードベースをクリーンな状態に保つ自由があります。そして私たちにとってそれはまちがいなく必須事項でした。」</p>
+
+<p>これから先を見据え、次にNavが意欲的に視野に入れているのは、トレーシング(Tracing)、ストレージ、そしてサービスメッシュです。そしてKubeConで多くの時間をいろんな企業との対話に費やしたその後で、現在彼らは<a href="https://www.envoyproxy.io/">Envoy</a>、 <a href="https://opentracing.io/">OpenTracing</a>、そして <a href="https://www.jaegertracing.io/">Jaeger</a>を検証しています。「コミュニティは非常に活発です。アイデアを出し合い、皆が直面する多くの類似課題について話すことができ、そして支援を得ることができます。私たちはさまざまな理由から同じ問題に取り組み、そこでお互いに助け合うことができる、そういう点が気に入っています」とJeppsonは言います。「クラウドネイティブなソリューションをフルに採用できるようになるには、スケーラビリティ面でやるべきことがまだたくさんあります。」</p>
+
+<p>もちろん、すべてはKubernetesから始まります。Jeppsonのチームは、この技術でNavをスケール可能にするプラットフォームを構築しました。そして「これまで経験したことのない新たな自由、たくさんの価値をNavにもたらしてくれたのです。」と彼は言います。新製品を検討しようにも、隔離された環境を用意するのに6か月待たなければならず、その後もトラフィックが急上昇するのに対応するやりかたも考え出さなければならないという事実があり、身動きが取れなくなってしまっていました。「しかし、もうそういった話もなくなりました。」とJeppsonは言います。「今私たちが扱っているトラフィック量の4〜10倍が流れたとしても、『ああ、大丈夫だよ、Kubernetesがやってくれるから』と話しています。」</p>

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
+  - 所在地: シアトル、ワシントン
+  - 業界: 小売り
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/nordstrom/banner1.jpg')">
+<h2>課題</h2>
-  <h1> ケーススタディ:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">厳しい小売環境下で数百万ドルのコスト削減を実現
+
+<p>NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。</p>
+
+<h2>解決策</h2>
+
+<p>4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、<a href="http://kubernetes.io/">Kubernetes</a>でオーケストレーションされたDockerコンテナを採用しました。</p>
+
+<h2>影響</h2>
+
+<p>Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」</p>
+
+{{< case-studies/quote author="Nordstrom社シニアエンジニア Dhawal Patel" >}}
+私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
+{{< /case-studies/quote >}}
+
+<p>5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者として<a href="http://shop.nordstrom.com/">Nordstrom</a>に入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。</p>
+
+<p>DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」</p>
+
+<p>同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。</p>
+
+<p>開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームは<a href="https://www.chef.io/chef/">Chef</a>を選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」</p>
+
+<p>しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。</p>
+
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}}
+「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」
+{{< /case-studies/quote >}}
+
+<p>「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」</p>
+
+<p>Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。</p>
+
+<p>Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」</p>
+
+<p>参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」</p>
+
+{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}}
+「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
+{{< /case-studies/quote >}}
 
 
-</div></h1>
+<p>これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のための<a href="https://prometheus.io/">Prometheus</a>と<a href="https://grafana.com/">Grafana</a>フロントエンドを組み合わせました。また、<a href="http://www.fluentd.org/">Fluentd</a>を使用してログを<a href="https://www.elastic.co/">Elasticsearch</a>にプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。</p>
 
-</div>
+<p>現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」</p>
 
-<div class="details">
+<p>Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。</p>
-    企業名 &nbsp;<b>Nordstrom</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>シアトル、ワシントン</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>小売り</b>
-</div>
 
-<hr>
+{{< case-studies/quote >}}
-<section class="section1">
+「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
-<div class="cols">
+{{< /case-studies/quote >}}
-  <div class="col1">
-    <h2>課題</h2>
- NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。
-<br>
-    <h2>解決策</h2>
- 4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、<a href="http://kubernetes.io/">Kubernetes</a>でオーケストレーションされたDockerコンテナを採用しました。
-  <br>
 
+<p>スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」</p>
 
-      </div>
+<p>Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」</p>
 
-<div class="col2">
+<p>そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」</p>
 
-  <h2>影響</h2>
+<p>この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」</p>
-  Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    私たちは常に、技術の最適化を通じてより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-Nordstrom社シニアエンジニア Dhawal Patel</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者として<a href="http://shop.nordstrom.com/">Nordstrom</a>に入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。
-<br><br>
-    DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」
-<br><br>
-    同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。
-<br><br>
-    開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームは<a href="https://www.chef.io/chef/">Chef</a>を選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」
-    <br><br>しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。
-
-</div>
-</section>
-<div class="banner3" style="background-image: url('/images/case-studies/nordstrom/banner3.jpg')">
-  <div class="banner3text">
-    「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」
-  </div>
-</div>
-<section class="section3">
-<div class="fullcol">
-
-「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」
-<br><br>
-Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。
-Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」
-<br><br>
-参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
-</div>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/nordstrom/banner4.jpg')">
-  <div class="banner4text">
- 「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
-  </div>
-</div>
-
-<section class="section5">
-<div class="fullcol">
-  これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のための<a href="https://prometheus.io/">Prometheus</a>と<a href="https://grafana.com/">Grafana</a>フロントエンドを組み合わせました。また、<a href="http://www.fluentd.org/">Fluentd</a>を使用してログを<a href="https://www.elastic.co/">Elasticsearch</a>にプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。
- <br><br>
-現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」
- <br><br>
-Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。
-</div>
-
-<div class="banner5">
-  <div class="banner5text">
- 「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
-  </div>
-</div>
-
-<div class="fullcol">
-  スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
-<br><br>
-  Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」
-  そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」
-<br><br>
-  この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」
-
-</div>
-</section>

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
+  - 所在地: フレゼレクスベア、デンマーク
+  - 業界: 医療および旅行支援
 ---
 
+<h2>課題</h2>
 
-<div class="banner1" style="background-image: url('/images/case-studies/sos/banner1.jpg')">
+<p>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」</p>
-  <h1>ケーススタディ:<img src="/images/sos_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供
 
-</div></h1>
+<h2>ソリューション</h2>
 
-</div>
+<p>標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。</p>
 
-<div class="details">
-    企業名 &nbsp;<b>SOS International</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>フレゼレクスベア、デンマーク
-</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>医療および旅行支援</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%"">
-    <h2>課題</h2>
- SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては
-3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「新しい技術と新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
-
-
-<br><br>
-    <h2>ソリューション</h2>
- 標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナ技術を包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
-<br><br>
 <h2>影響</h2>
- Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
-</div>
 
-</div>
+<p>Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しい技術に適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています」とAhrentsen氏は言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」</p>
-</section>
-<div class="banner2">
-  <div class="banner2text">
- 「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。</h2>
- SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。<br><br>
- ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
-<br><br>
- Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」
 
+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}}
+「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して導入することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。」
+{{< /case-studies/quote >}}
 
-</div>
+{{< case-studies/lead >}}
-</section>
+SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。
-<div class="banner3" style="background-image: url('/images/case-studies/sos/banner3.jpg')">
+{{< /case-studies/lead >}}
-  <div class="banner3text">
- 「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
 
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
+<p>SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。</p>
 
-  </div>
+<p>ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャ責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しい技術と新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」</p>
-</div>
-<section class="section3">
-<div class="fullcol">
- Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。<br><br>
 
- 技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」<br><br>
+<p>Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えた技術プラットフォームを見つけることにしました。」</p>
 
-プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
+{{< case-studies/quote
-</div>
+  image="/images/case-studies/sos/banner3.jpg"
-</section>
+  author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen"
-<div class="banner4" style="background-image: url('/images/case-studies/sos/banner4.jpg');width:100%">
+>}}
-  <div class="banner4text">
+「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
- 「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
+{{< /case-studies/quote >}}
- <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span>
-  </div>
-</div>
 
-<section class="section5" style="padding:0px !important">
+<p>Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。</p>
-<div class="fullcol">
- プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。<br><br>
 
- SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」<br><br>
+<p>技術やアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社にある3つのモノリスの中で、「2つ(.NETとJava)に対してこの最先端の技術を提供できます。」</p>
 
- しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。<br><br>
+<p>プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。</p>
 
- さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
+{{< case-studies/quote
+  image="/images/case-studies/sos/banner4.jpg"
+  author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen"
+>}}
+「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」
+{{< /case-studies/quote >}}
 
-</div>
+<p>プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。</p>
 
-<div class="banner5" >
+<p>SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「この技術を選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」</p>
-  <div class="banner5text">
- 「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
-<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen</span></div>
-</div>
 
-<div class="fullcol">
+<p>しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。</p>
- SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」<br><br>
 
- SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」<br><br>
+<p>さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しい技術を使いたいと思っています。」とAhrentsenは言います。「ITプロフェッショナルが新しい技術を提供したという理由で我が社を選んでいたことが新人研修の時にわかりました。」</p>
 
- 代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」<br><br>
+{{< case-studies/quote author="SOS International エンタープライズアーキテクチャ責任者 Martin Ahrentsen" >}}
+「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
+{{< /case-studies/quote >}}
 
- Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」
+<p>SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」</p>
-</div>
+
-</section>
+<p>SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」</p>
+
+<p>代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」</p>
+
+<p>Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブなソフトウェアや技術が現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべき技術は、デジタルの未来に向けてSOSに変化をもたらし始めました。」</p>

content/ja/case-studies/spotify/index.html

@@ -1,120 +1,82 @@
 ---
-title: Spotifyケーススタディ
+title: Spotify ケーススタディ
-linkTitle: Spotify 
+linkTitle: Spotify
 case_study_styles: true
 cid: caseStudies
-css: /css/style_case_studies.css
+featured: false
-logo: spotify_featured_logo.png 
-featured: true
-weight: 2
 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
+  - 所在地: グローバル
+  - 業界: エンターテイメント
 ---
 
-<div class="banner1" style="background-image: url('/images/case-studies/spotify/banner1.jpg')">
+<h2>課題</h2>
-  <h1> ケーススタディ：Spotify<br> <div class="subhead" style="margin-top:1%">Spotify：コンテナ技術のアーリーアダプターであるSpotifyは自社製オーケストレーションツールからKubernetesに移行しています
 
-</div></h1>
+<p>2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、<a href="https://github.com/spotify/helios">Helios</a>という自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。</p>
 
-</div>
+<h2>ソリューション</h2>
 
-<div class="details">
+<p>「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。</p>
-    企業名 &nbsp;<b>Spotify</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;所在地 &nbsp;<b>グローバル</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;業界 &nbsp;<b>エンターテイメント</b>
-</div>
-
-<hr>
-<section class="section1">
-<div class="cols">
-  <div class="col1" style="width:100%">
-    <h2>課題</h2>
-    2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。「私たちの目標は、クリエイターたちに力を与え、私たちが現在抱えるすべての消費者、そして願わくば将来抱える消費者が真に没入できる音楽体験を実現することです」、エンジニアリング、インフラおよびオペレーション担当ディレクターのJai Chakrabartiは、こう言います。マイクロサービスとDockerのアーリーアダプターであるSpotifyは、<a href="https://github.com/spotify/helios">Helios</a>という自社開発のコンテナオーケストレーションシステムを使い、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。2017年末までには、「こういった機能開発に自社の小さなチームで取り組むことは効率的ではなく、大きなコミュニティで支持されているものを採用したほうがよい」ことがはっきりしてきました。
-
-<br><br>
-    <h2>ソリューション</h2>
-    「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。」とChakrabartiは言います。KubernetesはHeliosよりも豊富な機能を有していました。さらに、「スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」また彼のチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。Heliosの稼働と並行して行われたマイグレーションは、スムーズにすすめることができました。それは「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったからです」とChakrabartiは言います。
 
 <h2>インパクト</h2>
-    2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
-    
-</div>
-</div>
-</section>
-<div class="banner2">
-  <div class="banner2text">
-    「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti</span>
-  </div>
-</div>
-<section class="section2">
-<div class="fullcol">
-  <h2>「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。 
-2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。</h2>
 
-<br><br>
+<p>2018年の後半に始まり、2019年に向けて大きな注力点となる本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「ほんの一部をKubernetesに移行したのですが、社内チームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とサイト・リライアビリティ・エンジニアのJames Wenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。</p>
-  マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」<br><br>しかし、2017年の終わりまでには、「小さなチームが<a href="https://github.com/spotify/helios">Helios</a>の機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。
 
+{{< case-studies/quote author="Spotify エンジニアリング、インフラおよびオペレーション担当ディレクター、Jai Chakrabarti" >}}
+「Kubernetesを中心に成長した素晴らしいコミュニティを見て、その一部になりたかったのです。スピードの向上とコスト削減のメリットを享受し、ベストプラクティスとツールについて業界の他の企業と連携したいとも思いました。」
+{{< /case-studies/quote >}}
 
-</div>
+{{< case-studies/lead >}}
-</section>
+「私たちのゴールは、クリエイターたちに力を与え、今・これからの消費者が真に没入できる音楽体験を実現することです。」Spotifyのエンジニアリング、インフラストラクチャおよびオペレーション担当ディレクター、Jai Chakrabartiは、このように述べています。2008年から始まったオーディオストリーミングプラットフォームは、アクティブユーザーが世界中で毎月2億人を超えるまでに成長しました。Chakrabartiのチームにとってのゴールは、将来のすべての消費者もサポートするべくSpotifyのインフラを強固なものにしていくことです。
-<div class="banner3" style="background-image: url('/images/case-studies/spotify/banner3.jpg')">
+{{< /case-studies/lead >}}
-  <div class="banner3text">
-    「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky</span>
 
-  </div>
+<p>マイクロサービスとDockerのアーリーアダプターであるSpotifyは、自社のVM全体にわたり実行されるマイクロサービスをコンテナ化していました。同社は「Helios」というオープンソースの自社製コンテナオーケストレーションシステムを使用し、2016年から17年にかけてオンプレミスのデータセンターからGoogle Cloudへの移行を完了しました。こういった意思決定の「我々にはさまざまなピースに取り組む、すばやく繰り返す作業を必要とする自律的なエンジニアリングチームが200以上あり、彼らを中心とした文化があります」とChakrabartiは言います。「したがって、チームがすばやく動けるようになる開発者のベロシティツールを持つことが非常に大事です。」</p>
-</div>
-<section class="section3">
-<div class="fullcol">
-  もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」
-    
-<br><br>
 
-チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。
+<p>しかし、2017年の終わりまでには、「小さなチームが<a href="https://github.com/spotify/helios">Helios</a>の機能に取り組むのは、それよりもはるかに大きなコミュニティで支持されているものと比べると効率的ではない」ことが明らかになった、とChakrabartiは言います。「Kubernetesを取り巻き成長した驚くべきコミュニティを見ました。その一員になりたいと思いました。スピードの向上とコストの削減による恩恵を受けたかったですし、ベストプラクティスとツールをもつ他の業界と連携したいとも思いました。」同時にこのチームは、活発なKubernetesコミュニティにその知見でコントリビュートし、影響を与えることも望みました。</p>
 
-<br><br>
+{{< case-studies/quote
-マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」
+  image="/images/case-studies/spotify/banner3.jpg"
-<br><br>
+  author="Spotify ソフトウェアエンジニア、インフラおよびオペレーション担当、Dave Zolotusky"
-今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。
+>}}
+「このコミュニティは、あらゆる技術への取り組みをより速く、より容易にしてくれることを強力に助けてくれました。そして、私たちの取り組みのすべてを検証することも助けてくれました。」
+{{< /case-studies/quote >}}
 
-「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。
+<p>もう1つのプラス：「KubernetesがHeliosを補完するものとして、そして今はHeliosを代替するものとして非常にフィットしたものだったので、リスク軽減のためにHeliosと同時に稼働させることができました」とChakrabartiは言います。「マイグレーションの最中はサービスが両方の環境で実行されるので、さまざまな負荷・ストレス環境下でKubernetesの有効性を確認できるようになるまではすべての卵を1つのバスケットに入れる必要がありません。」</p>
 
-Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。
+<p>チームは、本マイグレーションにおいて必要となる主要な技術の問題に対応するため、チームは2018年の大半を費やしました。「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能を多く使うことができたので、インテグレーションはシンプルで簡単なものでした」とサイト・リライアビリティ・エンジニアのJames Wenは言います。</p>
 
+<p>マイグレーションはその年の後半に始まり、2019年に加速しました。「私たちはステートレスなサービスに注力しています。最後に残る技術的課題を突破したら、それが上昇をもたらしてくれると期待しています」とChakrabartiは言います。「ステートフルサービスについては、より多くのやるべきことがあります。」</p>
 
-</div>
+<p>今のところ、Spotifyの150を超えるサービスのごく一部がKubernetesに移行されています。「社内のチームから聞こえてきたのは、手作業でのキャパシティプロビジョニングを意識する必要性が少なくなり、Spotifyとしての機能の提供に集中できる時間がより多くなってきたということです」とChakrabartiは言います。Kubernetesで現在実行されている最も大きなサービスはアグリゲーションサービスで、1秒あたり約1000万リクエストを受け取り、オートスケールによる大きな恩恵を受けている、とWenは言います。さらに、「以前はチームが新しいサービスを作り、運用ホストを本番環境で稼働させるために1時間待たなければなりませんでしたが、Kubernetesでは秒・分のオーダーでそれを実現できます」と付け加えます。さらに、Kubernetesのビンパッキング（組み合わせ最適化）機能やマルチテナント機能により、CPU使用率が平均して2〜3倍向上しました。</p>
-</section>
-<div class="banner4" style="background-image: url('/images/case-studies/spotify/banner4.jpg')">
-  <div class="banner4text">
-  「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify、Spotifyエンジニア、James Wen</span>
-  </div>
-</div>
 
-<section class="section5" style="padding:0px !important">
+{{< case-studies/quote
-<div class="fullcol">
+  image="/images/case-studies/spotify/banner4.jpg"
-  Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。
+  author="Spotify、Spotifyエンジニア、James Wen"
-<br><br>
+>}}
-Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」
+「レガシーのインフラをサポートしたり連携するKubernetes APIやKubernetesの拡張性機能をたくさん使うことができたので、インテグレーションはシンプルで簡単なものでした」
-<br><br>
+{{< /case-studies/quote >}}
-またSpotifyは<a href="https://grpc.io/">gRPC</a>と<a href="https://www.envoyproxy.io/">envoy</a>を使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」
 
+<p>Chakrabartiは、Spotifyが見ている4つのトップレベルのメトリック - リードタイム、デプロイ頻度、修復時間、そして運用負荷 - のすべてについて「Kubernetesがインパクトを与えている」と指摘します。</p>
 
-</div>
+<p>Kubernetesが初期の頃に出てきたサクセスストーリーの1つに、SpotifyチームがKubernetesの上に構築したSlingshotというツールがあります。「プルリクエストを出すと、24時間後に自己消滅する一時的なステージング環境を生成します」とChakrabartiは言います。「これはすべてKubernetesがやってくれています。新しいテクノロジーが出てきて使えるようになったときに、自分のイメージを超えるようなソリューションをいかにしてこの環境上で作っていくか、そのやり方を示す刺激的な例だと思います。」</p>
 
-<div class="banner5" >
+<p>またSpotifyは<a href="https://grpc.io/">gRPC</a>と<a href="https://www.envoyproxy.io/">envoy</a>を使い、Kubernetesと同じように、既存の自社製ソリューションを置き換え始めました。「私たちはその時の自分たちの規模を理由にした開発をしていて、実際に他のソリューションはありませんでした」とインフラおよび運用担当のソフトウェアエンジニアであるDave Zolotuskyは言います。「しかし、そういった規模感のツールですらコミュニティは私たちに追いつき、追い越して行きました。」</p>
-  <div class="banner5text">
-    「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」 <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-  Spotify、サイト・リライアビリティ・エンジニア、James Wen</span></div>
-</div>
 
+{{< case-studies/quote author="Spotify、サイト・リライアビリティ・エンジニア、James Wen" >}}
+「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました」
+{{< /case-studies/quote >}}
 
-<div class="fullcol">
+<p>どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」</p>
-  どちらの技術も採用するには初期段階ではありますが、「gRPCはスキーマ管理、API設計、下位互換の問題など、初期の開発段階における多くの問題に対してより劇的な影響を与えると確信しています」とZolotuskyは言います。「そのため、そういった領域でgRPCに傾倒しています。」
 
-<br><br>
+<p>チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです -  CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。</p>
-チームはSpotifyのクラウドネイティブなスタックを拡大し続けており - この次にあるのはスタックトレーシングです -  CNCFランドスケープを有用なガイドとして活用しています。「解決する必要があるものを見たときに、もし多数のプロジェクトがあればそれらを同じように評価しますが、そのプロジェクトがCNCFプロジェクトであることには間違いなく価値があります」とZolotuskyは言います。
 
-<br><br>
+<p>SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」</p>
-SpotifyがKubernetesでこれまでに経験してきたことはそれを裏付けています。「あらゆる技術により速くより簡単に取り組めるようになる点で、このコミュニティは極めて有益です」とZolotuskyは言います。「私たちが取り組んでいることに関する専門知識を得るために、コンタクトしたい人と連絡を取るのは驚くほど簡単でした。そして、私たちが行っていたすべての検証で役立ちました。」
-
-
-</div>
-</section>
-</body>
-</html>

content/ja/docs/concepts/architecture/cloud-controller.md

@@ -1,21 +1,18 @@
 ---
-title: クラウドコントローラーマネージャーとそのコンセプト
+title: クラウドコントローラーマネージャー
 content_type: concept
 weight: 40
 ---
 
 <!-- overview -->
 
-クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることができるように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
-クラウドコントローラーマネージャーの設計は「プラグインメカニズム」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合できるようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
+クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。
 
-このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="cloud-controller-managerは">}}
-
-これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。
-
-![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
 
+cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。
 
 
 
@@ -23,91 +20,49 @@ weight: 40
 
 ## 設計
 
-上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します:
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
 
-* Kubelet
+クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。
-* Kubernetesコントローラーマネージャー
-* Kubernetes APIサーバー
 
-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. ノードをクラウド特有のゾーン/リージョンラベルで初期化する
+1. Nodeオブジェクトを、コントローラーがクラウドプロバイダーAPIを通じて見つけた各サーバーで初期化する
-2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する
+2. Nodeオブジェクトに、ノードがデプロイされているリージョンや利用可能なリソース（CPU、メモリなど）のようなクラウド特有な情報を注釈付けやラベル付けをする
-3. ノードのネットワークアドレスとホスト名を取得する
+3. ノードのホスト名とネットワークアドレスを取得する
-4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する
+4. ノードの正常性を検証する。ノードが応答しなくなった場合、クラウドプロバイダーのAPIを利用しサーバーがdeactivated / deleted / terminatedであるかを確認する。クラウドからノードが削除されていた場合、KubernetesクラスターからNodeオブジェクトを削除する
+
+いくつかのクラウドプロバイダーは、これをノードコントローラーと個別のノードライフサイクルコントローラーに分けて実装しています。
 
 #### ルートコントローラー
 
-ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
+ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信できるように、クラウド内のルートを適切に設定する責務を持ちます。
+
+クラウドプロバイダーによっては、ルートコントローラーはPodネットワークのIPアドレスのブロックを割り当てることもあります。
 
 #### サービスコントローラー
 
-サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。さらに、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
+{{< glossary_tooltip text="Services" term_id="service" >}}は、マネージドロードバランサー、IPアドレスネットワークパケットフィルタや対象のヘルスチェックのようなクラウドインフラストラクチャーコンポーネントのインテグレーションを行います。サービスコントローラーは、ロードバランサーや他のインフラストラクチャーコンポーネントを必要とするServiceリソースを宣言する際にそれらのコンポーネントを設定するため、クラウドプロバイダーのAPIと対話します。
-
-### 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/)を参照してください。
 
 ## 認可
 
-このセクションでは、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)
+[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
-* [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)
 
+どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？
 
-## クラスター管理
+クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するために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`を使います。
-
-CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
 
+本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。
 
+プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。

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)を読んでください。
+

content/ja/docs/concepts/architecture/nodes.md

@@ -6,27 +6,107 @@ weight: 10
 
 <!-- overview -->
 
-ノードは、以前には `ミニオン` としても知られていた、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はコンテナを_Node_上で実行される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" >}}が含まれます。
 
 <!-- body -->
 
+## 管理 {#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" >}}のリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`)。 
+  
+  `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属性を考慮しません。
+これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、DaemonSetがマシンに属していることを前提としているためです。
+{{< /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 | 概要 |
+{{< table caption = "ノードのConditionと、各condition適用時の概要" >}}
-|----------------|-------------|
+| ノードのCondition       | 概要 |
-| `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
+|----------------------|-------------|
-| `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `Ready`              | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
-| `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
+| `DiskPressure`       | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `DiskPressure`    | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `MemoryPressure`     | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
-| `NetworkUnavailable`    | ノードのネットワークが適切に設定されていない場合に`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サーバーから削除され、それらの名前が解放されます。
+ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
-
-ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。
 
+ノードのライフサイクルコントローラーが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を排除する責務もあります。
+ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
-さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。
+さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。
-`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のリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`). `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 >}}
 
 {{< caution >}}
 `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
@@ -209,29 +250,29 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ
 
 ### ノードのキャパシティ
 
-ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
+Nodeオブジェクトはノードのリソースキャパシティ（CPUの数とメモリの量）を監視します。
-通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。
+[自己登録](#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はリソースの割当を決定する際にトポロジーのヒントを利用できます。
-
+詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
-## APIオブジェクト
-
-NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
-[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
-
 
 ## {{% heading "whatsnext" %}}
 
-* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。
+* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。
-* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)
+* [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)について読む。

content/ja/docs/concepts/cluster-administration/cloud-providers.md

@@ -0,0 +1,327 @@
+---
+title: クラウドプロバイダー
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。
+
+<!-- body -->
+### 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=<node private IP>`を指定してください。
+
+## 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://<keystone_ip>/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(`<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`の下で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の特定の機能を使用するように外部のロードバランサーを設定できます。

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="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または物理ホストと同様に扱うことができる、クリーンで後方互換性のあるモデルを生み出しています。
 
@@ -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/#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.
 
@@ -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
+Follow the "With Linux Bridge devices" section of
-tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
+[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
 

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/)を参照してください。
 
 

content/ja/docs/concepts/containers/_index.md

@@ -1,4 +1,33 @@
 ---
-title: "コンテナ"
+title: コンテナ
 weight: 40
+description: アプリケーションとランタイムの依存関係を一緒にパッケージ化するための技術
+reviewers:
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+
+実行するそれぞれのコンテナは繰り返し使用可能です。依存関係を含めて標準化されており、どこで実行しても同じ動作が得られることを意味しています。
+
+コンテナは基盤となるホストインフラからアプリケーションを切り離します。これにより、さまざまなクラウドやOS環境下でのデプロイが容易になります。
+
+
+
+
+<!-- body -->
+
+## コンテナイメージ
+[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
+
+設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。
+
+## コンテナランタイム
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* [コンテナイメージ](/docs/concepts/containers/images/)についてお読みください。
+* [Pod](/ja/docs/concepts/workloads/pods/)についてお読みください。

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](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
 
 ### フックハンドラーの実装
 
@@ -102,4 +102,3 @@ Events:
 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
 
 
-

content/ja/docs/concepts/containers/runtime-class.md

@@ -11,20 +11,18 @@ weight: 20
 
 このページではRuntimeClassリソースと、runtimeセクションのメカニズムについて説明します。
 
-{{< warning >}}
+RuntimeClassはコンテナランタイムの設定を選択するための機能です。そのコンテナランタイム設定はPodのコンテナを稼働させるために使われます。
-RuntimeClassはKubernetes1.14のβ版アップグレードにおいて*破壊的な* 変更を含んでいます。もしユーザーがKubernetes1.14以前のバージョンを使っていた場合、[RuntimeClassのα版からβ版へのアップグレード](#upgrading-runtimeclass-from-alpha-to-beta)を参照してください。
-{{< /warning >}}
-
-
 
 
 <!-- body -->
 
-## 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/)を参照してください。
+ノードの選択とtolerationsについての詳細は[ノード上へのPodのスケジューリング](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)を参照してください。
-
-[アドミッションコントローラー]: /docs/reference/access-authn-authz/admission-controllers/
 
 ### 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が稼働する時に関連するオーバーヘッドを指定することをサポートしています。
+Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
-`PodOverhead`を使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではoffです)
+Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
 
-PodのオーバーヘッドはRuntimeClass内の`Overhead`フィールドによって定義されます。
+PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
 このフィールドを使用することで、RuntimeClassを使用して稼働するPodのオーバーヘッドを指定することができ、Kubernetes内部で使用されるオーバーヘッドを確保することができます。
 
-### RutimeClassをα版からβ版にアップグレードする
 
-RuntimeClassのβ版の機能は、下記の変更点を含みます。
+## {{% heading "whatsnext" %}}
-
-- `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においてもはや有効ではありません。正しい形式のハンドラー設定に変更しなくてはなりません(先ほど記載した内容を確認ください)。
-
-
-### 参考文献
 
 - [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)

content/ja/docs/concepts/extend-kubernetes/_index.md

@@ -1,4 +1,164 @@
 ---
 title: Kubernetesを拡張する
 weight: 110
+description: Kubernetesクラスターの挙動を変えるいろいろな方法
+content_type: concept
+no_list: true
 ---
+
+<!-- overview -->
+Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
+結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
+このガイドは、Kubernetesクラスターをカスタマイズするための選択肢を記載します。
+管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
+将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
+<!-- body -->
+## 概要
+カスタマイズのアプローチには大きく分けて、フラグ、ローカル設定ファイル、またはAPIリソースの変更のみを含んだ *設定* と、稼働しているプログラムまたはサービスも含んだ *拡張* があります。このドキュメントでは、主に拡張について説明します。
+## 設定
+
+*設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
+
+ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
+
+[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+
+## 拡張
+
+拡張はKubernetesを拡張し、深く統合されたソフトウェアの構成要素です。
+これは新しいタイプと、新しい種類のハードウェアをサポートするために利用されます。
+
+ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
+結果として、ほとんどのKubernetesユーザーは既存の拡張を使えばよいため、新しい拡張を書く必要は無いと言えます。
+
+## 拡張パターン {#extension-patterns}
+
+Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
+Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
+*自動化機能* はクラスター上、またはクラスター外で実行できます。
+このドキュメントに後述のガイダンスに従うことで、高い可用性を持つ頑強な自動化機能を書くことができます。
+自動化機能は通常、ホスティングされているクラスター、マネージドな環境など、どのKubernetesクラスター上でも動きます。
+
+Kubernetes上でうまく動くクライアントプログラムを書くために、*コントローラー* パターンという明確なパターンがあります。
+コントローラーは通常、オブジェクトの `.spec` を読み取り、何らかの処理をして、オブジェクトの `.status` を更新します。
+
+コントローラーはKubernetesのクライアントです。Kubernetesがクライアントとして動き、外部のサービスを呼び出す場合、それは *Webhook* と呼ばれます。
+呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
+
+Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
+*バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
+
+下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
+
+<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
+
+## 拡張ポイント
+
+この図は、Kubernetesにおける拡張ポイントを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
+
+<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
+
+1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセス拡張](/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセス拡張と一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラー拡張](/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
+5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。
+
+もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類の拡張を含んでいることを留意してください。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
+
+<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
+
+## API拡張
+### ユーザー定義タイプ
+
+新しいコントローラー、アプリケーションの設定に関するオブジェクト、また宣言型APIを定義し、それらを`kubectl`のようなKubernetesのツールから管理したい場合、Kubernetesにカスタムリソースを追加することを検討して下さい。
+
+カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
+
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。
+
+### 新しいAPIと自動化機能の連携
+
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+
+### ビルトインリソースの変更
+
+カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI(例、Pod)の振る舞いに影響を与えることは無いですが、APIアクセス拡張の場合、その可能性があります。
+
+### APIアクセス拡張 {#api-access-extensions}
+
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+
+これらの各ステップごとに拡張ポイントが用意されています。
+
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。
+
+### 認証
+
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+
+Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
+
+### 認可
+
+[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可メカニズムが要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
+
+### 動的Admission Control
+
+リクエストが認可された後、もしそれが書き込み操作だった場合、リクエストは[Admission Control](/docs/reference/access-authn-authz/admission-controllers/)のステップを通ります。ビルトインのステップに加え、いくつかの拡張が存在します:
+
+*   [イメージポリシーWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)は、コンテナでどのイメージを実行することができるかを制限する
+*   任意のAdmission Controlの決定を行うには、一般的な[Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)が利用できる。Admission Webhookは作成、更新を拒絶できる
+
+## インフラストラクチャ拡張
+
+### ストレージプラグイン
+
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+
+### デバイスプラグイン
+
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+
+### ネットワークプラグイン
+
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。
+
+### スケジューラー拡張
+
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。
+
+これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
+
+スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラー拡張)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
+* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
+* インフラストラクチャ拡張についてより深く学ぶ
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
+* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ

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/)します
+* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)します
-* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
+* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/extend-kubernetes/setup-extension-api-server/)します
-* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
+* また、[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)の仕様をお読み下さい
 
 

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](/ja/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にアグリゲート(集約)する](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)か、もしくはAPIをスタンドアローンで動かすかを検討します。
 
 | APIアグリゲーションを使う場合: | スタンドアローンAPIを使う場合: |
 | ------------------------------ | ---------------------------- |
@@ -78,7 +78,7 @@ APIが宣言的ではない兆候として、次のものがあります:
 * ファイルが更新されたときに、Deploymentなどを介してローリングアップデートを行いたい
 
 {{< note >}}
-センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/docs/concepts/configuration/secret/)を使ってください
+センシティブなデータには、ConfigMapに類似していますがよりセキュアな[secret](/ja/docs/concepts/configuration/secret/)を使ってください
 {{< /note >}}
 
 下記のほとんどに該当する場合、カスタムリソース(CRD、またはアグリゲート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) | はい |
+| サブリソースのスケール | HorizontalPodAutoscalerやPodDisruptionBudgetなどのシステムが、新しいリソースと連携できるようにする | [はい](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | はい |
-| サブリソースの状態 | ユーザーがspecセクションに書き込み、コントローラーがstatusセクションに書き込む際に、より詳細なアクセスコントロールができるようにする。カスタムリソースのデータ変換時にオブジェクトの世代を上げられるようにする(リソース内のspecとstatusでセクションが分離している必要がある) | [はい](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-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,7 +166,7 @@ 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を利用 |
@@ -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/)について学ぶ

content/ja/docs/concepts/extend-kubernetes/extend-cluster.md

@@ -25,14 +25,14 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
 
 *設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
 
-* [kubelet](/docs/admin/kubelet/)
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
-* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
-* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
-* [kube-scheduler](/docs/admin/kube-scheduler/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
 
 ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
 
-[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/using-api/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
 
 ## エクステンション
 
@@ -58,7 +58,7 @@ Kubernetes上でうまく動くクライアントプログラムを書くため
 
 Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
 *バイナリプラグイン* モデルでは、Kubernetesはバイナリ(プログラム)を実行します。
-バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/))、またkubectlで利用されています。
+バイナリプラグインはkubelet(例、[FlexVolumeプラグイン](/docs/concepts/storage/volumes/#flexVolume)、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))、またkubectlで利用されています。
 
 下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
 
@@ -75,12 +75,12 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 
 1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
-2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/docs/concepts/overview/extending#api-access-extensions)セクションに記載されています。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/ja/docs/concepts/extend-kubernetes/#api-access-extensions)セクションに記載されています。
-3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/overview/extending#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
-4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/docs/concepts/overview/extending#scheduler-extensions)セクションに記載されています。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/ja/docs/concepts/extend-kubernetes/#scheduler-extensions)セクションに記載されています。
 5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
-6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/overview/extending#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/ja/docs/concepts/extend-kubernetes/#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
-7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/overview/extending#storage-plugins)を通じてサポートされます。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/ja/docs/concepts/extend-kubernetes/#storage-plugins)を通じてサポートされます。
 
 もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類のエクステンションを含んでいることを留意してください。
 
@@ -95,11 +95,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
 
-カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/docs/concepts/api-extension/custom-resources/)を参照して下さい。
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を参照して下さい。
 
 ### 新しいAPIと自動化機能の連携
 
-カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/ja/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
 
 ### ビルトインリソースの変更
 
@@ -111,11 +111,11 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 これらの各ステップごとに拡張ポイントが用意されています。
 
-Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて(Webhookの)検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/)でカバーされています。
 
 ### 認証
 
-[認証](/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
 
 Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
 
@@ -134,19 +134,19 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
 
 ### ストレージプラグイン
 
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+[Flex Volumes](/docs/concepts/storage/volumes/#flexVolume)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
 
 ### デバイスプラグイン
 
-[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
+[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を通じて、ノードが新たなノードのリソース(CPU、メモリなどのビルトインのものに加え)を見つけることを可能にします。
 
 ### ネットワークプラグイン
 
-他のネットワークファブリックが[ネットワークプラグイン](/docs/admin/network-plugins/)を通じてサポートされます。
+他のネットワークファブリックが[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)を通じてサポートされます。
 
 ### スケジューラーエクステンション
 
-スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/administer-cluster/configure-multiple-schedulers/)を同時に動かすこともできます。
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)を同時に動かすこともできます。
 
 これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
 
@@ -157,12 +157,10 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
 ## {{% heading "whatsnext" %}}
 
 
-* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
+* [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)についてより深く学ぶ
 * [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
 * インフラストラクチャエクステンションについてより深く学ぶ
-  * [ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)
+  * [ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
-  * [デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)
+  * [デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 * [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
 * [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
-
-

content/ja/docs/concepts/extend-kubernetes/operator.md

@@ -6,8 +6,8 @@ weight: 30
 
 <!-- overview -->
 
-オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
+オペレーターは[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)を使用するKubernetesへのソフトウェア拡張です。
-オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
+オペレーターは、特に[制御ループ](/ja/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/)として機能させることができます。
 
@@ -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)を読みます
 
-

content/ja/docs/concepts/overview/components.md

@@ -1,6 +1,8 @@
 ---
 title: Kubernetesのコンポーネント
 content_type: concept
+description: >
+  Kubernetesクラスターはコントロールプレーンやノードと呼ばれるマシン群といったコンポーネントからなります。
 weight: 20
 card: 
   name: concepts
@@ -53,20 +55,18 @@ Kubernetesをデプロイすると、クラスターが展開されます。
 
 ### cloud-controller-manager
 
-[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
-cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。
 
-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}
 
 ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。

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,80 @@ card:
 
 <!-- overview -->
 
-全般的なAPIの規則は、[API規則ドキュメント](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)に記載されています。
+Kubernetesの中核である {{< glossary_tooltip text="control plane" term_id="control-plane" >}}は{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} です。
-
+APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。
-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 APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
 
+APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。
 
 <!-- body -->
 
 ## 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仕様を提供しています。
+## OpenAPI 仕様 {#api-specification}
-リクエストフォーマットは、HTTPヘッダーを下記のように設定することで指定されます:
 
-ヘッダ | 設定可能な値
+完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。
------- | ---------------
-Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (デフォルトのcontent-typeは、`*/*`に対して`application/json`か、もしくはこのヘッダーを送信しません)
-Accept-Encoding | `gzip` (このヘッダーを送信しないことも許容されています)
 
-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で削除されました。
+Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOpenAPI仕様を提供します。
+次のように要求ヘッダーを使用して、応答フォーマットを要求できます。
 
-**OpenAPI仕様の取得サンプル**:
 
-1.10より前 | Kubernetes1.10以降
+<table>
------------ | -----------------------------
+  <thead>
-GET /swagger.json | GET /openapi/v2 **Accept**: application/json
+     <tr>
-GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
+        <th>Header</th>
-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
+        <th style="min-width: 50%;">Possible values</th>
+        <th>Notes</th>
+     </tr>
+  </thead>
+  <tbody>
+     <tr>
+        <td><code>Accept-Encoding</code></td>
+        <td><code>gzip</code></td>
+        <td><em>このヘッダーを使わないことも可能</em></td>
+     </tr>
+     <tr>
+        <td rowspan="3"><code>Accept</code></td>
+        <td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
+        <td><em>主にクラスター内での使用</em></td>
+     </tr>
+     <tr>
+        <td><code>application/json</code></td>
+        <td><em>デフォルト</em></td>
+     </tr>
+     <tr>
+        <td><code>*</code></td>
+        <td><code>application/json</code>を提供</td>
+     </tr>
+  </tbody>
+  <caption>OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
+</table>
+
 
 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 +107,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. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。
-1. 独自のAPIサーバーを実装可能な、フルセットのKubernetes APIが必要なユーザーは、[アグリゲーター](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)を使い、クライアントにシームレスな形で拡張を行います。
+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/)をご覧ください。

content/ja/docs/concepts/overview/what-is-kubernetes.md

@@ -71,11 +71,11 @@ 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は...
 
-* サポートするアプリケーションの種類を制限しません。Kubernetesは、スレートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
+* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
 * ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
 * ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
 * ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。

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

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`クエリが同じであることを意味します。  
+フィールドセレクターは本質的にリソースの _フィルター_ となります。デフォルトでは、セレクター/フィルターが指定されていない場合は、全てのタイプのリソースが取得されます。これは、`kubectl`クエリの`kubectl get pods`と`kubectl get pods --field-selector ""`が同じであることを意味します。  
-
-```shell
-kubectl get pods
-kubectl get pods --field-selector ""
-```
 {{< /note >}}
 
 ## サポートされているフィールド

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/)を学びましょう。
 
 

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選定](/ja/docs/concepts/scheduling-eviction/assign-pod-node/) のドキュメントを参照してください。 
 
 

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
+NAME              STATUS   AGE
-default       Active    1d
+default           Active   1d
-kube-system   Active    1d
+kube-node-lease   Active   1d
-kube-public   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の設定
 
@@ -79,7 +85,7 @@ kubectl config view --minify | grep namespace:
 
 ユーザーが[Service](/ja/docs/concepts/services-networking/service/)を作成するとき、Serviceは対応する[DNSエントリ](/ja/docs/concepts/services-networking/dns-pod-service/)を作成します。
 このエントリは`<service-name>.<namespace-name>.svc.cluster.local`という形式になり、これはもしあるコンテナがただ`<service-name>`を指定していた場合、Namespace内のローカルのServiceに対して名前解決されます。
-これはデベロップメント、ステージング、プロダクションといって複数のNamespaceをまたいで同じ設定を使う時に効果的です。
+これはデベロップメント、ステージング、プロダクションといった複数のNamespaceをまたいで同じ設定を使う時に効果的です。
 もしユーザーがNamespaceをまたいでアクセスしたい時、 完全修飾ドメイン名(FQDN)を指定する必要があります。
 
 ## すべてのオブジェクトはNamespaceに属しているとは限らない

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,8 @@ 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
+kubectl scale deployment nginx --replicas=2 --namespace=myspace
 ```
 
 ```shell
@@ -549,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)を参照してください。
 

content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -136,7 +136,7 @@ Nodeアフィニティを使用したPodの例を以下に示します:
 
 この例ではオペレーター`In`が使われています。
 Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
-`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
+`NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)に使用します。
 
 `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
 
@@ -186,10 +186,10 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin
 
 このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
-Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`topology.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
-Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
+Node Nがキー`topology.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
 Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
-(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
+(`topologyKey`が`topology.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
 
 PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
@@ -201,7 +201,7 @@ PodアフィニティとPodアンチアフィニティで使用できるオペ
 2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
 3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。
-4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
+4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができます。
 
 `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
 省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。
@@ -361,7 +361,7 @@ spec:
 ## {{% heading "whatsnext" %}}
 
 
-[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
+[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
 
 [Nodeアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
 [Pod間アフィニティ/アンチアフィニティ](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)

content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -98,7 +98,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 
 - `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。
 
-- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/)にて確認できます。
+- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にて確認できます。
 
 - `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。
 
@@ -106,7 +106,7 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 
 - `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
 
-- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
+- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
 
 - `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
 

content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -6,7 +6,7 @@ weight: 40
 
 
 <!-- overview -->
-[_Nodeアフィニティ_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)は
+[_Nodeアフィニティ_](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)は
 {{< glossary_tooltip text="Pod" term_id="pod" >}}の属性であり、ある{{< glossary_tooltip text="Node" term_id="node" >}}群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はNodeがある種のPodを排除できるようにします。
 
 _toleration_ はPodに適用され、一致するtaintが付与されたNodeへPodがスケジューリングされることを認めるものです。ただしそのNodeへ必ずスケジューリングされるとは限りません。

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の公開も可能です。

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
+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
+my-nginx   LoadBalancer   10.0.162.149     xx.xxx.xxx.xxx     8080:30163/TCP        21s
 ```
 ```
 curl https://<EXTERNAL-IP> -k

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設定上でさらに制御するための手段を提供します。
 

content/ja/docs/concepts/services-networking/endpoint-slices.md

@@ -0,0 +1,108 @@
+---
+title: EndpointSlice
+content_type: concept
+weight: 15
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+
+*EndpointSlice*は、Kubernetesクラスター内にあるネットワークエンドポイントを追跡するための単純な手段を提供します。EndpointSliceは、よりスケーラブルでより拡張可能な、Endpointの代わりとなるものです。
+
+<!-- body -->
+
+## 動機
+
+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)である必要があります。
+
+一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。
+
+```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
+```
+
+デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。
+
+EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
+
+### アドレスの種類
+
+EndpointSliceは次の3種類のアドレスをサポートします。
+
+* IPv4
+* IPv6
+* FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)
+
+### トポロジー
+
+EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
+
+* `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
+* `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
+* `topology.kubernetes.io/region` - このエンドポイントが存在するリージョン。
+
+これらのラベルの値はスライス内の各エンドポイントと関連するリソースから継承したものです。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は対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
+
+## EndpointSliceコントローラー
+
+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の分散
+
+それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。
+
+コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
+
+1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
+2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
+3. まだ追加するべき新しいエンドポイントが残っていた場合、これまで変更されなかったスライスに追加を試み、その後、新しいスライスを作成する。
+
+ここで重要なのは、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" %}}
+
+* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
+* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
+

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/)を参照してください。

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コントローラーは微妙に異なる動作をします。
 
@@ -65,14 +65,15 @@ spec:
   - http:
       paths:
       - path: /testpath
+        pathType: Prefix
         backend:
           serviceName: test
           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トラフィックに対してのルールのみサポートしています。
+Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
 
 ### Ingressのルール
 
@@ -86,10 +87,65 @@ Ingressコントローラーでは、デフォルトのバックエンドが設
 
 ### デフォルトのバックエンド
 
-ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、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
@@ -176,7 +232,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 >}}
 
 ### 名前ベースのバーチャルホスティング
@@ -268,16 +324,16 @@ metadata:
 spec:
   tls:
   - hosts:
-    - sslexample.foo.com
+      - sslexample.foo.com
     secretName: testsecret-tls
   rules:
-    - host: sslexample.foo.com
+  - host: sslexample.foo.com
-      http:
+    http:
-        paths:
+      paths:
-        - path: /
+      - path: /
-          backend:
+        backend:
-            serviceName: service1
+          serviceName: service1
-            servicePort: 80
+          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の更新
 
@@ -374,7 +430,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 +446,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)
-

content/ja/docs/concepts/services-networking/network-policies.md

@@ -0,0 +1,200 @@
+---
+title: ネットワークポリシー
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+
+ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
+
+NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
+
+<!-- body -->
+## 前提条件
+
+ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。
+
+## 分離されたPodと分離されていないPod
+
+デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。
+
+Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。)
+
+ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。
+
+## NetworkPolicyリソース {#networkpolicy-resource}
+
+リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。
+
+以下は、NetworkPolicyの一例です。
+
+```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 >}}
+選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。
+{{< /note >}}
+
+__必須フィールド__: 他の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)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。
+
+__podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。
+
+__policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に
+`Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。
+
+__ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。
+
+__egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。
+
+したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。
+
+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への接続を許可する
+
+追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。
+
+## `to`と`from`のセレクターの振る舞い
+
+`ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。
+
+__podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。
+
+__namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。
+
+__namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+      podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+    - podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。
+
+正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。
+
+__ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。
+
+クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。
+
+内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。
+
+外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。
+
+## デフォルトのポリシー
+
+デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。
+
+### デフォルトですべての内向きのトラフィックを拒否する
+
+すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。
+
+### デフォルトで内向きのすべてのトラフィックを許可する
+
+(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+
+### デフォルトで外向きのすべてのトラフィックを拒否する
+
+すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。
+
+### デフォルトで外向きのすべてのトラフィックを許可する
+
+(たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+
+### デフォルトで内向きと外向きのすべてのトラフィックを拒否する
+
+名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。
+
+{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+
+このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。
+
+## SCTPのサポート
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
+
+{{< note >}}
+SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+- [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。
+- NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。

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` という[フィーチャーゲート](/ja/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は`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。
 (もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、<NodeIP>はフィルターされた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を使用できます。
 
@@ -689,7 +728,7 @@ spec:
 
 {{< /note >}}
 
-#### Tencent Kubernetes Engine（TKE）におけるその他のCLBアノテーション
+#### Tencent Kubernetes Engine(TKE)におけるその他のCLBアノテーション
 
 以下に示すように、TKEでCloud Load Balancerを管理するためのその他のアノテーションがあります。
 
@@ -700,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: ""
@@ -714,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"
         # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
         # そうでない場合、すべてのノードが登録されます
@@ -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からのマイグレーションをサポートすることも必要です)。
-また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
+また、Kubernetesは(例えば、管理者の介入によって)無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
 
 ### ServiceのIPアドレス {#ips-and-vips}
 
@@ -894,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}
@@ -936,5 +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/)を参照してください。
-
-

content/ja/docs/concepts/storage/persistent-volumes.md

@@ -11,7 +11,7 @@ weight: 20
 
 <!-- overview -->
 
-このドキュメントではKubernetesの`PersistentVolume`について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
+このドキュメントではKubernetesの _PersistentVolume_ について説明します。[ボリューム](/docs/concepts/storage/volumes/)を一読することをおすすめします。
 
 
 
@@ -20,13 +20,13 @@ weight: 20
 
 ## 概要
 
-ストレージを管理することはインスタンスを管理することとは全くの別物です。`PersistentVolume`サブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するための`PersistentVolume`と`PersistentVolumeClaim`という2つの新しいAPIリソースを紹介します。
+ストレージを管理することはインスタンスを管理することとは全くの別物です。PersistentVolumeサブシステムは、ストレージが何から提供されているか、どのように消費されているかをユーザーと管理者から抽象化するAPIを提供します。これを実現するためのPersistentVolumeとPersistentVolumeClaimという2つの新しいAPIリソースを紹介します。
 
-`PersistentVolume`(PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
+_PersistentVolume_ (PV)は[ストレージクラス](/docs/concepts/storage/storage-classes/)を使って管理者もしくは動的にプロビジョニングされるクラスターのストレージの一部です。これはNodeと同じようにクラスターリソースの一部です。PVはVolumeのようなボリュームプラグインですが、PVを使う個別のPodとは独立したライフサイクルを持っています。このAPIオブジェクトはNFS、iSCSIやクラウドプロバイダー固有のストレージシステムの実装の詳細を捕捉します。
 
-`PersistentVolumeClaim`(PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、1ノードからのみ読み書きマウントができるモードや、複数ノードから読み込み専用マウントができるモードなどです)を要求することができます。
+_PersistentVolumeClaim_ (PVC)はユーザーによって要求されるストレージです。これはPodと似ています。PodはNodeリソースを消費し、PVCはPVリソースを消費します。Podは特定レベルのCPUとメモリーリソースを要求することができます。クレームは特定のサイズやアクセスモード(例えば、ReadWriteOnce、ReadOnlyMany、ReadWriteManyにマウントできます。詳しくは[アクセスモード](#access-modes)を参照してください)を要求することができます。
 
-`PersistentVolumeClaim`はユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持った`PersistentVolume`を必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々な`PersistentVolume`を提供できる必要があります。これらのニーズに応えるために`StorageClass`リソースがあります。
+PersistentVolumeClaimはユーザーに抽象化されたストレージリソースの消費を許可する一方、ユーザーは色々な問題に対処するためにパフォーマンスといった様々なプロパティを持ったPersistentVolumeを必要とすることは一般的なことです。クラスター管理者はユーザーに様々なボリュームがどのように実装されているかを表に出すことなく、サイズやアクセスモードだけではない色々な点で異なった、様々なPersistentVolumeを提供できる必要があります。これらのニーズに応えるために _StorageClass_ リソースがあります。
 
 [実例を含む詳細なチュートリアル](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)を参照して下さい。
 
@@ -45,8 +45,8 @@ PVは静的か動的どちらかでプロビジョニングされます。
 
 #### 動的
 
-ユーザーの`PersistentVolumeClaim`が管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
+ユーザーのPersistentVolumeClaimが管理者の作成したいずれの静的PVにも一致しない場合、クラスターはPVC用にボリュームを動的にプロビジョニングしようとする場合があります。
-このプロビジョニングは`StorageClass`に基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
+このプロビジョニングはStorageClassに基づいています。PVCは[ストレージクラス](/docs/concepts/storage/storage-classes/)の要求が必要であり、管理者は動的プロビジョニングを行うためにストレージクラスの作成・設定が必要です。ストレージクラスを""にしたストレージ要求は、自身の動的プロビジョニングを事実上無効にします。
 
 ストレージクラスに基づいたストレージの動的プロビジョニングを有効化するには、クラスター管理者が`DefaultStorageClass`[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)をAPIサーバーで有効化する必要があります。
 これは例えば、`DefaultStorageClass`がAPIサーバーコンポーネントの`--enable-admission-plugins`フラグのコンマ区切りの順序付きリストの中に含まれているかで確認できます。
@@ -114,19 +114,19 @@ Events:            <none>
 
 ### 再クレーム
 
-ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。`PersistentVolume`の再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
+ユーザーは、ボリュームの使用が完了したら、リソースの再クレームを許可するAPIからPVCオブジェクトを削除できます。PersistentVolumeの再クレームポリシーはそのクレームが解放された後のボリュームの処理をクラスターに指示します。現在、ボリュームは保持、リサイクル、または削除できます。
 
 #### 保持
 
-`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。`PersistentVolumeClaim`が削除される時、`PersistentVolume`は依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
+`Retain`という再クレームポリシーはリソースを手動で再クレームすることができます。PersistentVolumeClaimが削除される時、PersistentVolumeは依然として存在はしますが、ボリュームは解放済みです。ただし、以前のクレームデータはボリューム上に残っているため、別のクレームにはまだ使用できません。管理者は次の手順でボリュームを手動で再クレームできます。
 
-1. `PersistentVolume`を削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
+1. PersistentVolumeを削除します。PVが削除された後も、外部インフラストラクチャー(AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど)に関連付けられたストレージアセットは依然として残ります。
 1. ストレージアセットに関連するのデータを手動で適切にクリーンアップします。
-1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共に`PersistentVolume`を作成します。
+1. 関連するストレージアセットを手動で削除するか、同じストレージアセットを再利用したい場合、新しいストレージアセット定義と共にPersistentVolumeを作成します。
 
 #### 削除
 
-`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除すると`PersistentVolume`オブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[`StorageClass`の再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じて`StorageClass`を構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
+`Delete`再クレームポリシーをサポートするボリュームプラグインの場合、削除するとPersistentVolumeオブジェクトがKubernetesから削除されるだけでなく、AWS EBS、GCE PD、Azure Disk、Cinderボリュームなどの外部インフラストラクチャーの関連ストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、[StorageClassの再クレームポリシー](#reclaim-policy)を継承します。これはデフォルトで削除です。管理者は、ユーザーの需要に応じてStorageClassを構成する必要があります。そうでない場合、PVは作成後に編集またはパッチを適用する必要があります。[PersistentVolumeの再クレームポリシーの変更](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)を参照してください。
 
 #### リサイクル
 
@@ -136,7 +136,9 @@ Events:            <none>
 
 基盤となるボリュームプラグインでサポートされている場合、`Recycle`再クレームポリシーはボリュームに対して基本的な削除(`rm -rf /thevolume/*`)を実行し、新しいクレームに対して再び利用できるようにします。
 
-管理者は[こちら](/docs/admin/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+管理者は[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/)で説明するように、Kubernetesコントローラーマネージャーのコマンドライン引数を使用して、カスタムリサイクラーPodテンプレートを構成できます。カスタムリサイクラーPodテンプレートには、次の例に示すように、`volumes`仕様が含まれている必要があります。
+
+
 
 ```yaml
 apiVersion: v1
@@ -194,7 +196,7 @@ parameters:
 allowVolumeExpansion: true
 ```
 
-PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これにより`PersistentVolume`を受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しく`PersistentVolume`が作成されることはありません。代わりに既存のボリュームがリサイズされます。
+PVCに対してさらに大きなボリュームを要求するには、PVCオブジェクトを編集してより大きなサイズを指定します。これによりPersistentVolumeを受け持つ基盤にボリュームの拡大がトリガーされます。クレームを満たすため新しくPersistentVolumeが作成されることはありません。代わりに既存のボリュームがリサイズされます。
 
 #### CSIボリュームの拡張
 
@@ -231,10 +233,19 @@ FlexVolumeのリサイズは、基盤となるドライバーがリサイズを
 EBSの拡張は時間がかかる操作です。また変更は、ボリュームごとに6時間に1回までというクォータもあります。
 {{< /note >}}
 
+#### ボリューム拡張時の障害からの復旧
+
+基盤ストレージの拡張に失敗した際には、クラスターの管理者はPersistent Volume Claim (PVC)の状態を手動で復旧し、リサイズ要求をキャンセルします。それをしない限り、リサイズ要求は管理者の介入なしにコントローラーによって継続的に再試行されます。  
+
+1. PersistentVolumeClaim(PVC)にバインドされているPersistentVolume(PV)を`Retain`再クレームポリシーとしてマークします。
+2. PVCを削除します。PVは`Retain`再クレームポリシーを持っているため、PVCを再び作成したときにいかなるデータも失うことはありません。  
+3. `claimRef`エントリーをPVスペックから削除して、新しいPVCがそれにバインドできるようにします。これによりPVは`Available`になります。  
+4. PVより小さいサイズでPVCを再作成し、PVCの`volumeName`フィールドをPVの名前に設定します。これにより新しいPVCを既存のPVにバインドします。  
+5. PVを再クレームポリシーを復旧することを忘れずに行ってください。  
 
 ## 永続ボリュームの種類
 
-`PersistentVolume`の種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
+PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
 
 * GCEPersistentDisk
 * AWSElasticBlockStore
@@ -297,13 +308,22 @@ spec:
 
 ### ボリュームモード
 
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
-Kubernetes 1.9より前は、すべてのボリュームプラグインが永続ボリュームにファイルシステムを作成していました。現在はRawブロックデバイスを使うために`volumeMode`の値を`block`に設定するか、ファイルシステムを使うために`filesystem`を設定できます。値が省略された場合のデフォルトは`filesystem`です。これはオプションのAPIパラメーターです。
+KubernetesはPersistentVolumesの2つの`volumeModes`をサポートしています: `Filesystem`と`Block`です。  
+`volumeMode`は任意のAPIパラメーターです。  
+`Filesystem`は`volumeMode`パラメーターが省略されたときに使用されるデフォルトのモードです。  
+
+`volumeMode: Filesystem`であるボリュームはPodに*マウント*されてディレクトリになります。 ボリュームがブロックデバイスでデバイスが空の時、Kubernetesは初めてそれにマウントされる前にデバイスのファイルシステムを作成します。  
+
+`volumeMode`の値を`Block`に設定してボリュームをRAWブロックデバイスとして使用します。  
+このようなボリュームは、ファイルシステムを持たないブロックデバイスとしてPodに提示されます。  
+このモードは、Podとボリュームの間のファイルシステムレイヤなしにボリュームにアクセスする可能な限り最速の方法をPodに提供するのに便利です。一方で、Pod上で実行しているアプリケーションはRAWブロックデバイスの扱い方を知っていなければなりません。  
+Pod内で`volumeMode: Block`とともにボリュームを使用する例としては、[Raw Block Volume Support](#raw-block-volume-support)を参照してください。
 
 ### アクセスモード
 
-`PersistentVolume`は、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
+PersistentVolumeは、リソースプロバイダーがサポートする方法でホストにマウントできます。次の表に示すように、プロバイダーにはさまざまな機能があり、各PVのアクセスモードは、その特定のボリュームでサポートされる特定のモードに設定されます。たとえば、NFSは複数の読み取り/書き込みクライアントをサポートできますが、特定のNFSのPVはサーバー上で読み取り専用としてエクスポートされる場合があります。各PVは、その特定のPVの機能を記述する独自のアクセスモードのセットを取得します。
 
 アクセスモードは次の通りです。
 
@@ -476,7 +496,7 @@ PVCが`selector`を要求することに加えて`StorageClass`を指定する
 
 ## ボリュームとしてのクレーム
 
-Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援している`PersistentVolume`を取得します。次に、ボリュームがホストとPodにマウントされます。
+Podは、クレームをボリュームとして使用してストレージにアクセスします。クレームは、そのクレームを使用するPodと同じ名前空間に存在する必要があります。クラスターは、Podの名前空間でクレームを見つけ、それを使用してクレームを支援しているPersistentVolumeを取得します。次に、ボリュームがホストとPodにマウントされます。
 
 ```yaml
 apiVersion: v1
@@ -498,29 +518,26 @@ spec:
 
 ### 名前空間に関する注意
 
-`PersistentVolume`バインドは排他的であり、`PersistentVolumeClaim`は名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
+PersistentVolumeバインドは排他的であり、PersistentVolumeClaimは名前空間オブジェクトであるため、"多"モード(`ROX`、`RWX`)でクレームをマウントすることは1つの名前空間内でのみ可能です。
 
 ## Rawブロックボリュームのサポート
 
-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
 次のボリュームプラグインは、必要に応じて動的プロビジョニングを含むrawブロックボリュームをサポートします。
 
 * AWSElasticBlockStore
 * AzureDisk
+* CSI
 * FC (Fibre Channel)
 * GCEPersistentDisk
 * iSCSI
 * Local volume
+* OpenStack Cinder
 * RBD (Ceph Block Device)
-* VsphereVolume (alpha)
+* VsphereVolume 
 
-{{< note >}}
+### Rawブロックボリュームを使用した永続ボリューム {#persistent-volume-using-a-raw-block-volume}
-Kubernetes 1.9では、FCおよびiSCSIボリュームのみがrawブロックボリュームをサポートしていました。
-追加のプラグインのサポートは1.10で追加されました。
-{{< /note >}}
-
-### Rawブロックボリュームを使用した永続ボリューム
 
 ```yaml
 apiVersion: v1
@@ -584,7 +601,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
 
 ### ブロックボリュームのバインド
 
-ユーザーが`PersistentVolumeClaim`specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
+ユーザーがPersistentVolumeClaim specの`volumeMode`フィールドを使用してrawブロックボリュームの要求を示す場合、バインディングルールは、このモードをspecの一部として考慮しなかった以前のリリースとわずかに異なります。表にリストされているのは、ユーザーと管理者がrawブロックデバイスを要求するために指定可能な組み合わせの表です。この表は、ボリュームがバインドされるか、組み合わせが与えられないかを示します。静的にプロビジョニングされたボリュームのボリュームバインディングマトリクスはこちらです。
 
 | PVボリュームモード | PVCボリュームモード | 結果         |
 | -------------------|:-------------------:| ------------:|
@@ -610,7 +627,7 @@ Podにrawブロックデバイスを追加する場合は、マウントパス
 
 ボリュームスナップショットのデータソースからボリュームを復元する機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
 
-### ボリュームスナップショットから永続ボリュームクレームを作成する
+### ボリュームスナップショットから永続ボリュームクレームを作成する {#create-persistent-volume-claim-from-volume-snapshot}
 
 ```yaml
 apiVersion: v1
@@ -632,13 +649,11 @@ spec:
 
 ## ボリュームの複製
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)はCSIボリュームプラグインにのみ利用可能です。
-
-ボリュームの複製機能は、CSIボリュームプラグインのみをサポートするために追加されました。詳細については、[ボリュームの複製](/ja/docs/concepts/storage/volume-pvc-datasource/)を参照してください。
 
 PVCデータソースからのボリューム複製機能を有効にするには、apiserverおよびcontroller-managerで`VolumeSnapshotDataSource`フィーチャーゲートを有効にします。
 
-### 既存のPVCからの永続ボリュームクレーム作成
+### 既存のPVCからの永続ボリュームクレーム作成 {#create-persistent-volume-claim-from-an-existing-pvc} 
 
 ```yaml
 apiVersion: v1
@@ -664,7 +679,7 @@ spec:
 - 構成にPersistentVolumeClaimオブジェクトを含める(DeploymentやConfigMapと共に)
 - ユーザーが設定をインスタンス化する際にPersistentVolumeを作成する権限がない場合があるため、設定にPersistentVolumeオブジェクトを含めない。
 - テンプレートをインスタンス化する時にストレージクラス名を指定する選択肢をユーザーに与える
-  - ユーザーがストレージクラス名を指定する場合、`persistentVolumeClaim.storageClassName`フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
+  - ユーザーがストレージクラス名を指定する場合、persistentVolumeClaim.storageClassName フィールドにその値を入力する。これにより、クラスターが管理者によって有効にされたストレージクラスを持っている場合、PVCは正しいストレージクラスと一致する。
   - ユーザーがストレージクラス名を指定しない場合、`persistentVolumeClaim.storageClassName`フィールドはnilのままにする。これにより、PVはユーザーにクラスターのデフォルトストレージクラスで自動的にプロビジョニングされる。多くのクラスター環境ではデフォルトのストレージクラスがインストールされているが、管理者は独自のデフォルトストレージクラスを作成することができる。
 - ツールがPVCを監視し、しばらくしてもバインドされないことをユーザーに表示する。これはクラスターが動的ストレージをサポートしない(この場合ユーザーは対応するPVを作成するべき)、もしくはクラスターがストレージシステムを持っていない(この場合ユーザーはPVCを必要とする設定をデプロイできない)可能性があることを示す。
 

content/ja/docs/concepts/storage/volume-pvc-datasource.md

@@ -6,7 +6,6 @@ weight: 30
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
 
 
@@ -31,6 +30,7 @@ weight: 30
 * 複製は同じストレージクラス内でのみサポートされます。
     - 宛先ボリュームは、ソースと同じストレージクラスである必要があります。
     - デフォルトのストレージクラスを使用でき、仕様ではstorageClassNameを省略できます。
+* 複製は同じVolumeMode設定を使用する2つのボリューム間でのみ実行できます(ブロックモードのボリュームを要求する場合、ソースもブロックモードである必要があります)。
 
 
 ## プロビジョニング

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)をご覧ください。
 
 
 
 <!-- body -->
 
-## 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)を見てください。

content/ja/docs/concepts/workloads/controllers/daemonset.md

@@ -2,7 +2,7 @@
 reviewers:
 title: DaemonSet
 content_type: concept
-weight: 50
+weight: 40
 ---
 
 <!-- overview -->
@@ -11,12 +11,11 @@ _DaemonSet_ は全て(またはいくつか)のNodeが単一のPodのコピー
 
 DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
-- `glusterd`や`ceph`のようなクラスターのストレージデーモンを各Node上で稼働させる。
+- クラスターのストレージデーモンを全てのNode上で稼働させる。
-- `fluentd`や`filebeat`のようなログ集計デーモンを各Node上で稼働させる。
+- ログ集計デーモンを全ての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をカバーする1つのDaemonSetが使用されるケースがあります。
+シンプルなケースとして、各タイプのデーモンにおいて、全てのNodeをカバーする1つのDaemonSetが使用されるケースがあります。さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
-さらに複雑な設定では、単一のタイプのデーモン用ですが、異なるフラグや、異なるハードウェアタイプに対するメモリー、CPUリクエストを要求する複数のDaemonSetを使用するケースもあります。
 
 
 
@@ -27,8 +26,7 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
 
 ### DaemonSetの作成
 
-ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。  
+ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させる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`フィールドが必須となります。  
+他の全ての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/)といったドキュメントを参照ください。
-設定ファイルの活用法に関する一般的な情報は、[アプリケーションのデプロイ](/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テンプレート](/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`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 {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。
 
-### 特定のいくつかのNode上のみにPodを稼働させる
+### 選択したNode上でPodを稼働させる
 
 もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node
-selector](/ja/docs/concepts/configuration/assign-pod-node/)にマッチするPodをNode上に作成します。  
+selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするPodをNode上に作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)マッチするPodをNode上に作成します。
-同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/configuration/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)の設定を尊重します。  
+DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
-下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
 
-| Toleration Key                           | Effect     | Version | Description                                                  |
+| Toleration Key                           | Effect     | Version | Description |
-| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
+| ---------------------------------------- | ---------- | ------- | ----------- |
-| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+    | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
+| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSetのPodはネットワーク分割のようなNodeの問題が発生したときに除外されません。|
-| `node.kubernetes.io/unreachable`         | 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/disk-pressure`       | NoSchedule | 1.8+    | |
-| `node.kubernetes.io/memory-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/unschedulable`       | NoSchedule | 1.12+   | DaemonSetのPodはデフォルトスケジューラーによってスケジュール不可能な属性を許容(tolerate)します。 |
-| `node.kubernetes.io/network-unavailable` | 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/)と呼ばれます。  
+Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
-DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
 
 ### Deployment
 
@@ -168,4 +162,3 @@ DaemonSetは、Podの作成し、そのPodが停止されることのないプ
 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。
 Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。
 
-

content/ja/docs/concepts/workloads/controllers/deployment.md

@@ -6,14 +6,14 @@ feature:
     Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。
 
 content_type: concept
-weight: 30
+weight: 10
 ---
 
 <!-- overview -->
 
-_Deployment_ は[Pod](/ja/docs/concepts/workloads/pods/pod/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)の宣言的なアップデート機能を提供します。
+_Deployment_ は{{< glossary_tooltip text="Pod" term_id="pod" >}}と{{< glossary_tooltip term_id="replica-set" text="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を作成することを検討してください。
@@ -44,21 +44,22 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 この例では、
 
 * `.metadata.name`フィールドで指定された`nginx-deployment`という名前のDeploymentが作成されます。
-* このDeploymentは`replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
+* このDeploymentは`.spec.replicas`フィールドで指定された通り、3つのレプリカPodを作成します。
-* `selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
+* `.spec.selector`フィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(`app: nginx`)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。
 
     {{< note >}}
-    `matchLabels`フィールドはキーバリューペアのマップです。`matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
+    `.spec.selector.matchLabels`フィールドはキーバリューペアのマップです。
+    `matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。
     `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。
     {{< /note >}}
 
 * `template`フィールドは、以下のサブフィールドを持ちます。:
-  * Podは`labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
+  * Podは`.metadata.labels`フィールドによって指定された`app: nginx`というラベルがつけられます。
   * PodTemplate、または`.template.spec`フィールドは、Podが`nginx`という名前で[Docker Hub](https://hub.docker.com/)にある`nginx`のバージョン1.14.2が動くコンテナを1つ動かすことを示します。
-  * 1つのコンテナを作成し、`name`フィールドを使って`nginx`という名前をつけます。
+  * 1つのコンテナを作成し、`.spec.template.spec.containers[0].name`フィールドを使って`nginx`という名前をつけます。
 
-上記のDeploymentを作成するためには以下のステップにしたがってください。
 作成を始める前に、Kubernetesクラスターが稼働していることを確認してください。
+上記のDeploymentを作成するためには以下のステップにしたがってください:
 
 1. 以下のコマンドを実行してDeploymentを作成してください。
 
@@ -67,11 +68,12 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   ```
 
   {{< note >}}
-  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
+  実行したコマンドを`kubernetes.io/change-cause`というアノテーションに記録するために`--record`フラグを指定できます。
+  これは将来的な問題の調査のために有効です。例えば、各Deploymentのリビジョンにおいて実行されたコマンドを見るときに便利です。
   {{< /note >}}
 
 
-2. Deploymentが作成されたことを確認するために、`kubectl get deployment`を実行してください。
+2. Deploymentが作成されたことを確認するために、`kubectl get deployments`を実行してください。
 
   Deploymentがまだ作成中の場合、コマンドの実行結果は以下のとおりです。
   ```shell
@@ -95,14 +97,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   deployment.apps/nginx-deployment successfully rolled out
   ```
 
-4. 数秒後、再度`kubectl get deployments`を実行してください。コマンドの実行結果は以下のとおりです。
+4. 数秒後、再度`kubectl get deployments`を実行してください。
+  コマンドの実行結果は以下のとおりです。
   ```shell
   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
   nginx-deployment   3/3     3            3           18s
   ```
   Deploymentが3つ全てのレプリカを作成して、全てのレプリカが最新(Podが最新のPodテンプレートを含んでいる)になり、利用可能となっていることを確認してください。
 
-5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです。
+5. Deploymentによって作成されたReplicaSet(`rs`)を確認するには`kubectl get rs`を実行してください。コマンドの実行結果は以下のとおりです:
   ```shell
   NAME                          DESIRED   CURRENT   READY   AGE
   nginx-deployment-75675f5897   3         3         3       18s
@@ -110,15 +113,15 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   ReplicaSetの出力には次のフィールドが表示されます:
 
   * `NAME`は、名前空間内にあるReplicaSetの名前の一覧です。
-  * `DESIRED`は、アプリケーションの理想的な_レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが_理想的な状態_ と呼ばれるものです。
+  * `DESIRED`は、アプリケーションの理想的な _レプリカ_ の値です。これはDeploymentを作成したときに定義したもので、これが _理想的な状態_ と呼ばれるものです。
   * `CURRENT`は現在実行されているレプリカの数です。
   * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
   * `AGE`は、アプリケーションが稼働してからの時間です。
 
   ReplicaSetの名前は`[Deployment名]-[ランダム文字列]`という形式になることに注意してください。ランダム文字列はランダムに生成され、pod-template-hashをシードとして使用します。
 
-
+6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。
-6. 各Podにラベルが自動的に付けられるのを確認するには`kubectl get pods --show-labels`を実行してください。コマンドの実行結果は以下のとおりです。
+  コマンドの実行結果は以下のとおりです:
   ```shell
   NAME                                READY     STATUS    RESTARTS   AGE       LABELS
   nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
@@ -128,7 +131,9 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   作成されたReplicaSetは`nginx`Podを3つ作成することを保証します。
 
 {{< note >}}
-Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
+Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。
+
+ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
 {{< /note >}}
 
 ### pod-template-hashラベル
@@ -468,7 +473,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
 
     実行結果は以下のとおりです。
     ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
     ```
     その他に、`--to-revision`を指定することにより特定のリビジョンにロールバックできます。
 
@@ -478,7 +483,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
 
     実行結果は以下のとおりです。
     ```
-    deployment.apps/nginx-deployment
+    deployment.apps/nginx-deployment rolled back
     ```
 
     ロールアウトに関連したコマンドのさらなる情報は[`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)を参照してください。
@@ -756,7 +761,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し
 
 ### Deploymentの更新処理 {#progressing-deployment}
 
-以下のタスクが実行中のとき、KubernetesはDeploymentの状態を_progressing_ にします。
+以下のタスクが実行中のとき、KubernetesはDeploymentの状態を _進行中_ にします。
 
 * Deploymentが新しいReplicaSetを作成します。
 * Deploymentが新しいReplicaSetをスケールアップさせています。
@@ -767,7 +772,7 @@ Deploymentは、そのライフサイクルの間に様々な状態に遷移し
 
 ### Deploymentの更新処理の完了 {#complete-deployment}
 
-Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを_complete_ にします。
+Deploymentが以下の状態になったとき、KubernetesはDeploymentのステータスを _完了_ にします。
 
 * Deploymentの全てのレプリカが、指定された最新のバージョンに更新されます。これは指定した更新処理が完了したことを意味します。
 * Deploymentの全てのレプリカが利用可能になります。
@@ -782,7 +787,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
 deployment.apps/nginx-deployment successfully rolled out
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが0となります（成功です）:
+```shell
+echo $?
+```
+```
 0
 ```
 
@@ -821,7 +831,8 @@ Kubernetesは停止状態のDeploymentに対して、ステータス状態を報
 {{< /note >}}
 
 {{< note >}}
-Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
+Deploymentを停止すると、Kubernetesは指定したデッドラインを超えたかどうかチェックしません。
+ロールアウトの途中でもDeploymentを安全に一時停止でき、デッドラインを超えたイベントをトリガーすることなく再開できます。
 {{< /note >}}
 
 設定したタイムアウトの秒数が小さかったり、一時的なエラーとして扱える他の種類のエラーが原因となり、Deploymentで一時的なエラーが出る場合があります。例えば、リソースの割り当てが不十分な場合を考えます。Deploymentの詳細情報を確認すると、以下のセクションが表示されます。
@@ -903,7 +914,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
 ```
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
-$ echo $?
+```
+そして`kubectl rollout`の終了ステータスが1となります(エラーを示しています):
+```shell
+echo $?
+```
+```
 1
 ```
 
@@ -925,7 +941,8 @@ Deploymentを使って一部のユーザーやサーバーに対してリリー
 
 ## Deployment Specの記述
 
-他の全てのKubernetesの設定と同様に、Deploymentは`apiVersion`、`kind`や`metadata`フィールドを必要とします。設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
+他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
+設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
 Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
 Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。
 
@@ -933,7 +950,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
 
 `.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
 
-`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては[Pod](/ja/docs/concepts/workloads/pods/pod/)と同じスキーマとなります。
+`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
 
 Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
 
@@ -967,6 +984,10 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 `.spec.strategy.type==Recreate`と指定されているとき、既存の全てのPodは新しいPodが作成される前に削除されます。
 
+{{< note >}}
+これは更新のための作成の前にPodを停止する事を保証するだけです。Deploymentを更新する場合、古いリビジョンのPodは全てすぐに停止されます。削除に成功するまでは、新しいリビジョンのPodは作成されません。手動でPodを削除すると、ライフサイクルがReplicaSetに制御されているのですぐに置き換えが実施されます（たとえ古いPodがまだ停止中のステータスでも）。Podに"高々この程度の"保証を求めるならば[StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)の使用を検討してください。
+{{< /note >}}
+
 #### Deploymentのローリングアップデート
 
 `.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。
@@ -985,7 +1006,7 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 ### progressDeadlineSeconds
 
-`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
+`.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。
 
 この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。
 
@@ -993,10 +1014,6 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成
 
 `.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。
 
-### rollbackTo
-
-`.spec.rollbackTo`は、`extensions/v1beta1`と`apps/v1beta1`のAPIバージョンにおいて非推奨で、`apps/v1beta2`以降のAPIバージョンではサポートされません。かわりに、[前のリビジョンへのロールバック](#rolling-back-to-a-previous-revision)で説明されているように`kubectl rollout undo`を使用するべきです。
-
 ### リビジョン履歴の保持上限
 
 Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに保持されています。

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`というグループバージョンにおいて、従属オブジェクトはデフォルトで削除されます。
 
 下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。
 

content/ja/docs/concepts/workloads/controllers/job.md

@@ -1,387 +0,0 @@
----
-title: Job
-content_type: concept
-feature:
-  title: バッチ実行
-  description: >
-    Kubernetesはサービスに加えて、バッチやCIのワークロードを管理し、必要に応じて失敗したコンテナを置き換えることができます。
-weight: 60
----
-
-<!-- overview -->
-
-Jobは1つ以上のPodを作成し、指定された数のPodが正常に終了することを保証します。
-JobはPodの正常終了を追跡します。正常終了が指定された回数に達すると、そのタスク(つまりJob)は完了します。Jobを削除すると、そのJobが作成したPodがクリーンアップされます。
-
-簡単な例としては、1つのPodを確実に実行して完了させるために、1つのJobオブジェクトを作成することです。
-ノードのハードウェア障害やノードの再起動などにより最初のPodが失敗したり削除されたりした場合、Jobオブジェクトは新たなPodを立ち上げます。
-
-また、Jobを使用して複数のPodを並行して実行することもできます。
-
-
-
-
-<!-- body -->
-
-## 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:       <none>
-    Host Port:  <none>
-    Command:
-      perl
-      -Mbignum=bpi
-      -wle
-      print bpi(2000)
-    Environment:  <none>
-    Mounts:       <none>
-  Volumes:        <none>
-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の自動クリーンアップ
-
-終了した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/)を使用することができます。

content/ja/docs/concepts/workloads/controllers/replicaset.md

@@ -2,7 +2,7 @@
 reviewers:
 title: ReplicaSet
 content_type: concept
-weight: 10
+weight: 20
 ---
 
 <!-- overview -->
@@ -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の代替案

content/ja/docs/concepts/workloads/controllers/statefulset.md

@@ -2,7 +2,7 @@
 reviewers:
 title: StatefulSet
 content_type: concept
-weight: 40
+weight: 30
 ---
 
 <!-- overview -->
@@ -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状態になるまでは停止されません。
 
@@ -167,7 +176,7 @@ Kubernetes1.7とそれ以降のバージョンでは、StatefulSetは`.spec.podM
 
 ## アップデートストラテジー
 
-Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStarategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
+Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spec.updateStrategy`フィールドで、コンテナの自動のローリングアップデートの設定やラベル、リソースのリクエストとリミットや、StatefulSet内のPodのアノテーションを指定できます。
 
 ### OnDelete
 
@@ -199,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/)の例を参考にしてください。
-

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
 ---
 
 <!-- overview -->
@@ -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="Job" 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に対してのみサポートされています。クラスターオペレーターはこの[例](/ja/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)のように、Jobの`.spec.ttlSecondsAfterFinished`フィールドを指定することにより、終了したJob(`完了した`もしくは`失敗した`)を自動的に削除するためにこの機能を使うことができます。  
 TTLコントローラーは、そのリソースが終了したあと指定したTTLの秒数後に削除できるか推定します。言い換えると、そのTTLが期限切れになると、TTLコントローラーがリソースをクリーンアップするときに、そのリソースに紐づく従属オブジェクトも一緒に連続で削除します。注意点として、リソースが削除されるとき、ファイナライザーのようなライフサイクルに関する保証は尊重されます。
 
 TTL秒はいつでもセット可能です。下記はJobの`.spec.ttlSecondsAfterFinished`フィールドのセットに関するいくつかの例です。
@@ -50,8 +50,6 @@ Kubernetesにおいてタイムスキューを避けるために、全てのNode
 ## {{% heading "whatsnext" %}}
 
 
-[Jobの自動クリーンアップ](/docs/concepts/workloads/controllers/jobs-run-to-completion/#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)
-
 
+* [設計ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)

content/ja/docs/concepts/workloads/pods/init-containers.md

@@ -29,7 +29,7 @@ Initコンテナのステータスは、`.status.initContainerStatuses`フィー
 
 Initコンテナは、リソースリミット、ボリューム、セキュリティ設定などのアプリケーションコンテナの全てのフィールドと機能をサポートしています。しかし、Initコンテナに対するリソースリクエストやリソースリミットの扱いは異なります。[リソース](#resources)にて説明します。
 
-また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`readinessProbe`をサポートしていません。
+また、InitコンテナはそのPodの準備ができる前に完了しなくてはならないため、`lifecycle`、`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に定義された順番に従ってPodのInitコンテナを起動します。各Initコンテナは次のInitコンテナが起動する前に正常に終了しなくてはなりません。もしあるInitコンテナがランタイムもしくはエラーにより起動失敗した場合、そのPodの`restartPolicy`の値に従ってリトライされます。しかし、もしPodの`restartPolicy`が`Always`に設定されていた場合、Initコンテナの`restartPolicy`は`OnFailure`が適用されます。
 
 Podは全てのInitコンテナが完了するまで`Ready`状態となりません。Initコンテナ上のポートはServiceによって集約されません。初期化中のPodのステータスは`Pending`となりますが、`Initialized`という値はtrueとなります。
 

content/ja/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -6,186 +6,110 @@ weight: 30
 
 <!-- overview -->
 
-このページでは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上で実行されます。
 
 
 <!-- body -->
 
-## 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の各フェーズの値と意味は厳重に守られています。
+Podの各フェーズの値と意味は厳重に守られています。ここに記載されているもの以外に`phase`の値は存在しないと思ってください。
-ここに記載されているもの以外に`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}
+Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
-
-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)に依存しています。
 
 ## コンテナのステータス {#container-states}
 
-PodがスケジューラによってNodeに割り当てられると、
+Pod全体の[フェーズ](#pod-phase)と同様に、KubernetesはPod内の各コンテナの状態を追跡します。[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/)を使用して、コンテナのライフサイクルの特定のポイントで実行するイベントをトリガーできます。
-kubeletはコンテナのランタイムを使用してコンテナの作成を開始します。
-コンテナの状態はWaiting、RunningまたはTerminatedの3ついずれかです。
-コンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。
-Pod内のコンテナごとにStateの項目として表示されます。
 
-* `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
+Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]`のコマンドを使用します。Pod内のコンテナごとにStateの項目として表示されます。
-   ...
-      State:          Waiting
-       Reason:       ErrImagePull
-   ...
-   ```
 
-* `Running`: コンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。この状態にはコンテナが実行中状態に入った時刻も表示されます。
+各状態の意味は次のとおりです。
 
-   ```yaml
+### `Waiting` {#container-state-waiting}
-   ...
-      State:          Running
-       Started:      Wed, 30 Jan 2019 16:46:38 +0530
-   ...
-   ```
 
-* `Terminated`: コンテナの実行が完了しコンテナの実行が停止したことを示します。コンテナは実行が正常に完了したときまたは何らかの理由で失敗したときにこの状態になります。いずれにせよ理由と終了コード、コンテナの開始時刻と終了時刻が表示されます。コンテナがTerminatedに入る前に`preStop`フックがあれば実行されます。
+コンテナが`Running`または`Terminated`のいずれの状態でもない場合コンテナは`Waiting`の状態になります。Waiting状態のコンテナは引き続きコンテナイメージレジストリからイメージを取得したり{{< glossary_tooltip text="Secret" term_id="secret" >}}を適用したりするなど必要な操作を実行します。`Waiting`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Waiting`の状態である理由の要約が表示されます。
 
-   ```yaml
+### `Running` {#container-state-running}
-   ...
-      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
-    ...
-   ```
 
-## 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に拡張性を持たせるため、
+追加のフィードバックやシグナルをPodStatus:_Pod readiness_に注入できるようにします。これを使用するには、Podの`spec`で`readinessGates`を設定して、kubeletが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を評価する追加の状態を指定できます。
+ReadinessゲートはPodの`status.conditions`フィールドの現在の状態によって決まります。Kubernetesが`Podのstatus.conditions`フィールドでそのような状態を発見できない場合、ステータスはデフォルトで`False`になります。
-KubernetesがPodのstatus.conditionsフィールドでそのような状態を発見できない場合、
+
-ステータスはデフォルトで`False`になります。以下はその例です。
+以下はその例です。
 
 ```yaml
 Kind: Pod
@@ -209,130 +133,139 @@ status:
 ...
 ```
 
-新しいPod Conditionは、Kubernetesの[label key format](/ja/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)に準拠している必要があります。
+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が導入されると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`フィールドがあります。
+[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つの種類があります:
-デフォルト値は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は別のポートにバインドされ直すことはありません。
 
-## Podのライフタイム {#pod-lifetime}
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+  コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
 
-一般にPodは人間またはコントローラーが明示的に削除するまで存在します。
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
-コントロールプレーンは終了状態のPod(SucceededまたはFailedの`phase`を持つ)の数が設定された閾値（kube-controller-manager内の`terminated-pod-gc-threshold`によって定義される）を超えたとき、それらのPodを削除します。
+  PodのIPの特定のポートにTCPチェックを行います。
-これはPodが作成されて時間とともに終了するため、リソースリークを避けます。
+  そのポートが空いていれば診断を成功とみなします。
 
-次の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/)を使用します。
+各Probe 次の3つのうちの一つの結果を持ちます:
-   Jobは`restartPolicy`がOnFailureまたはNeverになるPodに対してのみ適切です。
 
-- 停止することを期待しない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が含まれます。
+* `livenessProbe`: コンテナが動いているかを示します。
-Podを自分で直接作成するのではなく適切なコントローラを作成してPodを作成させることをおすすめします。
+   livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。
-これはPod単独ではマシンの障害に対して回復力がないためです。コントローラにはこの機能があります。
+   コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。
 
-Nodeが停止したりクラスタの他のNodeから切断された場合、
+* `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。
-Kubernetesは失われたノード上のすべてのPodの`phase`をFailedに設定するためのポリシーを適用します。
+   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によって実行されるため、
+### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe}
-すべてのリクエストはkubeletネットワークのnamespaceで行われます。
 
-```yaml
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-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
-```
 
-### statesの例
+コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です.
+この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは正常終了しました。
+Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。
-     * 完了のイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: Podの`phase`はSucceededになります。
-       * Never: Podの`phase`はSucceededになります。
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナは失敗終了しました。
+### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe}
-     * 失敗イベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: Podの`phase`はFailedになります。
 
-   * Podが実行中で、その中には2つのコンテナがあります。コンテナ1は失敗終了しました。
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-     * 失敗イベントを記録します。
-     * `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になります。
 
-   * Podが実行中でそのPodには1つのコンテナがあります。コンテナはメモリーを使い果たしました。
+Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。
-     * コンテナは失敗で終了します。
+この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。
-     * OOMイベントを記録します。
-     * `restartPolicy`が、
-       * Always: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * OnFailure: コンテナを再起動します。Podの`phase`はRunningのままです。
-       * Never: 失敗イベントを記録します。Podの`phase`はFailedになります。
 
-   * Podが実行中ですがディスクは死んでいます。
+コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。
-     * すべてのコンテナを殺します。
-     * 適切なイベントを記録します。
-     * Podの`phase`はFailedになります。
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
 
-   * Podが実行中ですがNodeが切り離されました。
+{{< note >}}
-     * Nodeコントローラがタイムアウトを待ちます。
+Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。
-     * NodeコントローラがPodの`phase`をFailedにします。
+{{< /note >}}
-     * Podがコントローラで作成されていた場合は、別の場所で再作成されます。
+
+### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。
+コンテナの起動時間が、`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=<seconds>` オプションをサポートします。
+
+`--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 +277,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)を参照してください

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)を参照して下さい。
 

content/ja/docs/concepts/workloads/pods/pod.md

@@ -1,188 +0,0 @@
----
-reviewers:
-title: Pod
-content_type: concept
-weight: 20
----
-
-<!-- overview -->
-
-_Pod_ は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。
-
-
-
-
-<!-- body -->
-
-## 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=<seconds>` オプションをサポートします。
-値 `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)を参照してください 。

content/ja/docs/concepts/workloads/pods/podpreset.md

@@ -6,25 +6,36 @@ weight: 50
 ---
 
 <!-- overview -->
-このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。  
+{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
 
+このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
 
 
 <!-- body -->
 ## PodPresetを理解する
 
-`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。
+`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
-ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
 
-PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。  
+PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
-この方法により、特定の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-<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)を参照してください。
-
-

content/ja/docs/contribute/localization.md

@@ -54,8 +54,8 @@ card:
 #### 既存のページの誤字脱字や古い記述を修正する場合の手順
 
 1. `kubernetes/website`リポジトリをフォークする
-2. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
+2. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)から任意の名前でブランチを作成し、該当箇所を編集する
-3. `dev-1.18-ja.1`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
+3. `dev-1.18-ja.2`(最新のマイルストーンブランチに適宜読み替えること)ブランチに向けてPull Requestを作成する
 
 ### マイルストーンについて {#milestones}
 

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)
 
 ## 設計のドキュメント
 

content/ja/docs/reference/access-authn-authz/authentication.md

@@ -13,7 +13,15 @@ weight: 10
 
 すべてのKubernetesクラスターには、2種類のユーザーがあります。Kubernetesによって管理されるサービスアカウントと、通常のユーザーです。
 
-通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点において、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+クラスターから独立したサービスは通常のユーザーを以下の方法で管理することを想定されています。
+
+- 秘密鍵を配布する管理者
+- KeystoneやGoogle Accountsのようなユーザーストア
+- ユーザー名とパスワードのリストを持つファイル
+
+これを考慮すると、 _Kubernetesは通常のユーザーアカウントを表すオブジェクトを持ちません。_ APIコールを介して、通常のユーザーをクラスターに追加することはできません。
+
+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と通信できるようにします。
 
@@ -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

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のアフィニティまたはアンチアフィニティ](/ja/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`サブリソースを有効にします。
+- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
-- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
+- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にします。
-- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
+- `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`プロパティも有効にします。
+- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-resources-containers/)の消費を有効にして、[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)ストレージ消費を監視します。
+- `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/)で確認できます。
+- `Sysctls`: 各Podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
-- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。
+- `TaintBasedEvictions`: ノードのTaintとPodのTolerationに基づいてノードからPodを排除できるようにします。。詳細は[TaintとToleration](/docs/concepts/scheduling-eviction/taint-and-toleration/)で確認できます。
-- `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
+- `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のオーバーレイモードで実行できるようにします。
 
@@ -402,4 +441,3 @@ GAになってからさらなる変更を加えることは現実的ではない
 ## {{% heading "whatsnext" %}}
 
 * Kubernetesの[非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)では、機能とコンポーネントを削除するためのプロジェクトのアプローチを説明しています。
-

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をリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
+
+<!--more-->
+
+Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。

content/ja/docs/reference/glossary/control-plane.md

@@ -11,3 +11,15 @@ tags:
 - fundamental
 ---
  コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
+
+ <!--more-->
+
+ このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。
+
+ * {{< glossary_tooltip text="etcd" term_id="etcd" >}}
+ * {{< 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" >}}と呼ばれていました。

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を実行します。
 
 <!--more--> 
 
-各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。
+各レプリカは{{< glossary_tooltip text="Pod" term_id="pod" >}}で表され、Podはクラスターの{{< glossary_tooltip text="ノード" term_id="node" >}}間で分散されます。
+ローカル状態を要求するワークロードには、{{< glossary_tooltip term_id="StatefulSet" >}}の利用を考えてください。

content/ja/docs/reference/glossary/node.md

@@ -15,3 +15,4 @@ tags:
 <!--more--> 
 
 ワーカーノードは、クラスターに応じて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"と呼ばれていました。

content/ja/docs/reference/glossary/platform-developer.md

@@ -14,4 +14,4 @@ tags:
 
 <!--more--> 
 
-プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/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のコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。

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の紐付けを簡単にします。
-

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 text="Pod" term_id="pod" >}}内の{{< glossary_tooltip text="コンテナ" term_id="container" >}}からアクセス可能です。
 
-<!--more--> 
+<!--more-->
 
-Kubernetesボリュームはボリュームを含むPodが存在する限り有効です。そのためボリュームはPod内で実行されるすべてのコンテナよりも長持ちし、コンテナの再起動後もデータは保持されます。
+Kubernetesボリュームはボリュームを含んだPodが存在する限り有効です。そのため、ボリュームはPod内で実行されるどのコンテナよりも長く存在し、コンテナが再起動してもボリューム内のデータは維持されます。
 
-詳しくは[ストレージ](https://kubernetes.io/docs/concepts/storage/)をご覧下さい。
+詳しくは[ストレージ](/ja/docs/concepts/storage/)をご覧ください。

content/ja/docs/reference/kubectl/cheatsheet.md

@@ -8,7 +8,7 @@ card:
 
 <!-- overview -->
 
-[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,10 +63,10 @@ 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のサブコマンドのネームスペースを永続的に変更します
+# 現在のコンテキストでkubectlのサブコマンドの名前空間を永続的に変更します
 kubectl config set-context --current --namespace=ggckad-s2
 
 # 特定のユーザー名と名前空間を使用してコンテキストを設定します
@@ -141,18 +141,18 @@ EOF
 
 ```bash
 # Getコマンドで基本的な情報を確認します
-kubectl get services                          # 現在のネームスペース上にあるすべてのサービスのリストを表示します
+kubectl get services                          # 現在の名前空間上にあるすべてのサービスのリストを表示します
-kubectl get pods --all-namespaces             # すべてのネームスペース上にあるすべてのPodのリストを表示します
+kubectl get pods --all-namespaces             # すべての名前空間上にあるすべてのPodのリストを表示します
-kubectl get pods -o wide                      # 現在のネームスペース上にあるすべてのPodについてより詳細なリストを表示します
+kubectl get pods -o wide                      # 現在の名前空間上にあるすべてのPodについてより詳細なリストを表示します
 kubectl get deployment my-dep                 # 特定のDeploymentを表示します
-kubectl get pods                              # 現在のネームスペース上にあるすべてのPodのリストを表示します
+kubectl get pods                              # 現在の名前空間上にあるすべてのPodのリストを表示します
 kubectl get pod my-pod -o yaml                # PodのYAMLを表示します
 
 # Describeコマンドで詳細な情報を確認します
 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を実行します
+mynamespace                                         # 特定の名前空間でnginx Podを実行します
-kubectl run nginx --image=nginx --restart=Never     # nginx Podを実行し、マニフェストファイルををpod.yamlという名前で書き込みます
+kubectl run nginx --image=nginx                     # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます
---dry-run -o yaml > 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=<spec>` | カスタムカラムを使用してコンマ区切りのテーブルを表示します
+`-o=custom-columns=<spec>` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します
 `-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
 `-o=json`     | JSON形式のAPIオブジェクトを出力します
 `-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
@@ -354,13 +363,27 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 `-o=wide`     | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
 `-o=yaml`     | YAML形式のAPIオブジェクトを出力します
 
+`-o=custom-columns`を使用したサンプル:
+
+```bash
+# クラスター内で実行中のすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
+
+# "k8s.gcr.io/coredns:1.6.2"を除いたすべてのイメージ名を表示する
+kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
+
+# 名前に関係なくmetadata以下のすべてのフィールドを表示する
+kubectl get pods -A -o=custom-columns='DATA:metadata.*'
+```
+
+
 ### Kubectlのログレベルとデバッグ
 kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
 
 ログレベル    | 説明
 --------------| -----------
 `--v=0`       | これは、クラスターオペレーターにログレベルが0であることを"常に"見えるようにするために役立ちます
-`--v=1`       | 冗長性が必要ない場合は、妥当なデフォルトのログレベルです
+`--v=1`       | ログレベルが必要ない場合に、妥当なデフォルトのログレベルです
 `--v=2`       | サービスに関する重要な定常状態情報と、システムの重要な変更に関連する可能性がある重要なログメッセージを表示します。 これは、ほとんどのシステムで推奨されるデフォルトのログレベルです。
 `--v=3`       | 変更に関するより詳細なログレベルを表示します
 `--v=4`       | デバックにむいたログレベルで表示します
@@ -374,12 +397,10 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
 ## {{% heading "whatsnext" %}}
 
 
-* kubectlについてより深く学びたい方は[kubectl概要](/docs/reference/kubectl/overview/)をご覧ください。
+* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)をご覧ください。
 
 * オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
 
 * また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。
 
 * コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
-
-

content/ja/docs/reference/kubectl/overview.md

@@ -8,9 +8,9 @@ card:
 ---
 
 <!-- overview -->
-`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/)をご覧ください。
 
 
 <!-- body -->
@@ -29,11 +29,11 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 * `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。
 
-      ```shell
+   ```shell
-      kubectl get pod pod1
+   kubectl get pod pod1
-      kubectl get pods pod1
+   kubectl get pods pod1
-      kubectl get po pod1
+   kubectl get po pod1
-      ```
+   ```
 
 * `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。
 
@@ -49,7 +49,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 
    * リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。
 
-      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/docs/concepts/configuration/overview/#general-configuration-tips)。<br/>
+      * 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
      例: `kubectl get pod -f ./pod.yaml`
 
 * `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>
@@ -64,41 +64,59 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。
 
-操作       | 構文    |       説明
+操作&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;       | 構文    |       説明
 -------------------- | -------------------- | --------------------
+`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。
 `annotate`    | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 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`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 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 <file-spec-src> <file-spec-dest> [options]` | コンテナとの間でファイルやディレクトリをコピーします。
 `create`        | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。
 `delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。
 `describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 1つ以上のリソースの詳細な状態を表示します。
 `diff`        | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
+`drain`    | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
 `edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
 `explain`    | `kubectl explain  [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
 `expose`        | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
 `get`        | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 1つ以上のリソースを表示します。
+`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。
 `label`        | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのラベルを、追加または更新します。
 `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。
+`options`    | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。
 `patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 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]` | 指定したイメージを、クラスタ上で実行します。
+`rollout`    | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
-`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | していしたReplicationControllerのサイズを更新します。
+`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
+`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定した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`    | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 実験中の機能: 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 +172,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 ## 出力オプション
 
-ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/user-guide/kubectl/)リファレンスドキュメントをご覧ください。
+ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。
 
 ### 出力のフォーマット
 
@@ -187,13 +205,12 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
 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=<spec>`または`-o custom-columns-file=<filename>`のようにテンプレートファイルを使用するかを選択できます。
 
-
 ##### 例
 
 インラインで定義する例は、以下の通りです。
@@ -214,10 +231,9 @@ kubectl get pods <pod-name> -o custom-columns-file=template.txt
 NAME          RSRC
 metadata.name metadata.resourceVersion
 ```
-
 どちらのコマンドを実行した場合でも、以下の結果を得ます。
 
-```shell
+```
 NAME           RSRC
 submit-queue   610995
 ```
@@ -228,22 +244,21 @@ submit-queue   610995
 つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
 これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。
 
-この機能は、`kubectl`1.11以降ではデフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
+この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
 
 ##### 例
 
 Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。
 
-
 ```shell
 kubectl get pods <pod-name> --server-print=false
 ```
 
 以下のように出力されます。
 
-```shell
+```
-NAME       READY     STATUS              RESTARTS   AGE
+NAME       AGE
-pod-name   1/1       Running             0          1m
+pod-name   1m
 ```
 
 ### オブジェクトリストのソート
@@ -314,6 +329,7 @@ kubectl describe pods/<pod-name>
 
 # ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
 # ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
+kubectl describe pods <rc-name>
 
 # すべてのPodの詳細を表示します。
 kubectl describe pods
@@ -329,8 +345,8 @@ kubectl describe pods
 # pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
 kubectl delete -f pod.yaml
 
-# name=<label-name>というラベルを持つPodとServiceをすべて削除します。
+# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
-kubectl delete pods,services -l name=<label-name>
+kubectl delete pods,services -l <label-key>=<label-value>
 
 # 初期化されていないPodを含む、すべてのPodを削除します。
 kubectl delete pods --all
@@ -340,14 +356,13 @@ kubectl delete pods --all
 
 ```shell
 # Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
-kubectl exec <pod-name> date
+kubectl exec <pod-name> -- date
 
 # Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
-kubectl exec <pod-name> -c <container-name> date
+kubectl exec <pod-name> -c <container-name> -- date
 
 # インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
-Get an interactive TTY and run /bin/bash from pod <pod-name>. By default, output is from the first container.
+kubectl exec -ti <pod-name> -- /bin/bash
-kubectl exec -ti <pod-name> /bin/bash
 ```
 
 `kubectl logs` - Pod内のコンテナのログを表示します。
@@ -378,16 +393,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 +417,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 +434,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 +455,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 +480,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)を御覧ください。

content/ja/docs/setup/_index.md

@@ -17,12 +17,11 @@ card:
 <!-- overview -->
 
 このセクションでは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)を参照してください。
 
 

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=<filename> 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/
 
 

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
 
-<br>
-
-{{< 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](https://pr.k8s.io/10653/files) and [#10778](https://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)
+  * [InfluxDB and Grafana](https://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)
+  * [kubedns, dnsmasq, and sidecar](https://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)
+  * [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 ElasticSearch Plugin](https://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 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).
+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).
-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.
 
 ### 少数のノードの起動の失敗を許容する
 

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
+Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
+これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
+完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。
-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").
 
-Multizone support is deliberately limited: a single Kubernetes cluster can run
+マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。
-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).
 
 
 ## 機能性
 
-When nodes are started, the kubelet automatically adds labels to them with
+ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。
-zone information.
 
-Kubernetes will automatically spread the pods in a replication controller
+Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード，異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。
-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.
 
-When persistent volumes are created, the `PersistentVolumeLabel`
+永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。
-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.
 
 ## 制限
 
-There are some important limitations of the multizone support:
+マルチゾーンサポートにはいくつか重要な制限があります:
 
-* We assume that the different zones are located close to each other in the
+* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。
-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.
 
-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
+* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。
-work if you directly specify an EBS volume in the pod spec (for example).
 
-* Clusters cannot span clouds or regions (this functionality will require full
+* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。
-federation support).
 
-* Although your nodes are in multiple zones, kube-up currently builds
+*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。
-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.
 
 ### ボリュームの制限
-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
+以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。
-  pod affinity or anti-affinity policies.
 
-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
+* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。
-  may not provide a uniform distribution of storage across zones.
 
-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
+* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。
-  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
+* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
 
 ## 全体の流れ
 
-We're now going to walk through setting up and using a multi-zone
+GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。
-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`).
 
 ### クラスターの立ち上げ
 
-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,37 +71,33 @@ 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
+このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
+
 
 ### ノードはラベルが付与される
 
-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
+それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`topology.kubernetes.io/region`がリージョンに、`topology.kubernetes.io/zone`はゾーンに付けられています:
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
+
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
 ```
 
 ### 2つ目のゾーンにさらにノードを追加
 
-Let's add another set of nodes to the existing cluster, reusing the
+それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。
-existing master, running in a different zone (us-central1-b or us-west-2b).
+kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。
-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.
 
 GCE:
 
@@ -152,37 +105,36 @@ 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
+ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです:
-in us-central1-b:
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-The output is similar to this:
+結果は以下のようになります:
 
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
 ```
 
 ### ボリュームのアフィニティ
 
-Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
+動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています):
 
 ```bash
 kubectl apply -f - <<EOF
@@ -210,30 +162,28 @@ EOF
 ```
 
 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
+バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。
-the configured zones. For version 1.2, dynamic persistent volumes were
+バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。
-always created in the zone of the cluster master
+(ここではus-central1-a / us-west-2a); このイシューは
-(here us-central1-a / us-west-2a); that issue
 ([#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
+pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
 ```
 
-So now we will create a pod that uses the persistent volume claim.
+では永続ボリュームクレームを使用するPodを作成します。
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
+GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します:
-this means that this pod can only be created in the same zone as the volume:
 
 ```yaml
 kubectl apply -f - <<EOF
@@ -255,8 +205,7 @@ spec:
 EOF
 ```
 
-Note that the pod was automatically created in the same zone as the volume, as
+一般的にゾーンを跨いだアタッチはクラウドプロバイダーによって許可されていないため、Podは自動的にボリュームと同じゾーンに作成されることに注意してください:
-cross-zone attachments are not generally permitted by cloud providers:
 
 ```shell
 kubectl describe pod mypod | grep Node
@@ -266,7 +215,7 @@ kubectl describe pod mypod | grep Node
 Node:        kubernetes-minion-9vlv/10.240.0.5
 ```
 
-And check node labels:
+ノードのラベルをチェックします:
 
 ```shell
 kubectl get node kubernetes-minion-9vlv --show-labels
@@ -274,13 +223,12 @@ kubectl get node kubernetes-minion-9vlv --show-labels
 
 ```shell
 NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
 ```
 
 ### Podがゾーンをまたがって配置される
 
-Pods in a replication controller or service are automatically spread
+レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう:
-across zones.  First, let's launch more nodes in a third zone:
 
 GCE:
 
@@ -294,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
 ```
 
-Verify that you now have nodes in 3 zones:
+3つのゾーンにノードがあることを確認します:
 
 ```shell
 kubectl get nodes --show-labels
 ```
 
-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
+シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します:
 
 ```shell
 find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
 ```
 
-The pods should be spread across all 3 zones:
+Podは3つの全てのゾーンにデプロイされているはずです:
 
 ```shell
 kubectl describe pod -l app=guestbook | grep Node
@@ -324,50 +272,49 @@ kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion
 
 ```shell
 NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
 ```
 
 
-Load-balancers span all zones in a cluster; the guestbook-go example
+ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます:
-includes an example load-balanced service:
 
 ```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:
 
@@ -397,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
 ```
 
-

content/ja/docs/setup/best-practices/node-conformance.md

@@ -3,7 +3,6 @@ title: ノードのセットアップの検証
 weight: 30
 ---
 
-{{< toc >}}
 
 ## ノード適合テスト
 

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
+    client_address=172.17.0.1
-   	method=GET
+    method=GET
-   	real path=/
+    real path=/
-   	query=
+    query=
-   	request_version=1.1
+    request_version=1.1
-   	request_scheme=http
+    request_scheme=http
-   	request_uri=http://192.168.99.100:8080/
+    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=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
+もしVMドライバーを変更したい場合は、`--driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
 
 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```
 
 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))
+* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
+* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* 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)を参照してください。
+* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。
-* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。
+* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。
-* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。
+* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。
-* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。
+* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。
-* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。
+* **新しいアドオンの追加**: 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: " をつけてください。

content/ja/docs/setup/production-environment/container-runtimes.md

@@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ
 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、
 コンテナホストシステム上で任意のコマンドを実行する可能性があります。
 
-この問題の更なる情報は以下のリンクを参照してください。
+この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。
-[cve-2019-5736 : runc vulnerability](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" >}}
+{{% tab name="Ubuntu 16.04+" %}}
-# Docker CEのインストール
+
+```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 \
+containerd.io=1.2.13-2 \
-  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
+docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.4~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 <<EOF
 {
@@ -99,33 +108,47 @@ cat > /etc/docker/daemon.json <<EOF
   "storage-driver": "overlay2"
 }
 EOF
+```
 
+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```
 
+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
+```
-{{< 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 \
+  containerd.io-1.2.13 \
-  docker-ce-19.03.4 \
+  docker-ce-19.03.11 \
-  docker-ce-cli-19.03.4
+  docker-ce-cli-19.03.11
+```
 
+```shell
 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
+```
 
+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -140,15 +163,26 @@ cat > /etc/docker/daemon.json <<EOF
   ]
 }
 EOF
+```
 
+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```
 
+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
+```
+{{% /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
+yum install -y cri-o
-{{< /tab >}}
+```
+{{% /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" >}}
+{{% /tab %}}
-# containerdのインストール
+{{% 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

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=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
+1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。
 
 コントロールプレーンノードを初期化するには、次のコマンドを実行します。

content/ja/docs/tasks/_index.md

@@ -5,82 +5,8 @@ weight: 50
 content_type: concept
 ---
 
-{{< toc >}}
-
 <!-- overview -->
 
-Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。
+Kubernetesドキュメントのこのセクションには、個々のタスクの実行方法を示すページが含まれています。タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
-タスクページは、通常、短い手順を実行することにより、1つのことを行う方法を示します。
-
-
-
-<!-- body -->
-
-## 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/)を参照してください。
-
 
+タスクページを作成したい場合は、[ドキュメントのPull Requestの作成](/docs/contribute/new-content/open-a-pr/)を参照してください。

content/ja/docs/tasks/access-application-cluster/_index.md

@@ -1,4 +1,5 @@
 ---
 title: "クラスター内アプリケーションへのアクセス"
+description: クラスター内アプリケーションへアクセスできるようにするために、ロードバランシングやポートフォワーディングの設定、ファイアウォールやDNS設定のセットアップを行います。
 weight: 60
 ---

content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md

@@ -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
+```