Merge branch 'master' into issue#28062

Makefile

@@ -19,7 +19,11 @@ help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
 
 module-check:
-	@git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2
+	@git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2
+
+module-init:
+	@echo "Initializing submodules..." 1>&2
+	@git submodule update --init --recursive --depth 1
 
 all: build ## Build site with production settings and put deliverables in ./public
 

README-de.md

@@ -37,6 +37,13 @@ Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein speziel
 
 > Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen).
 
+Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
+
+```
+#Füge das Docsy submodule hinzu
+git submodule update --init --recursive --depth 1
+```
+
 Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal:
 
 ```bash
@@ -55,9 +62,18 @@ make container-serve
 
 Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist.
 
+Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
+
+```
+#Füge das Docsy submodule hinzu
+git submodule update --init --recursive --depth 1
+```
+
 So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben:
 
 ```bash
+# Installieren der JavaScript Abhängigkeiten
+npm ci
 make serve
 ```
 

README-zh.md

@@ -174,7 +174,7 @@ Learn more about SIG Docs Kubernetes community and meetings on the [community pa
 
 You can also reach the maintainers of this project at:
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 -->
 # 参与 SIG Docs 工作
@@ -184,7 +184,7 @@ You can also reach the maintainers of this project at:
 
 你也可以通过以下渠道联系本项目的维护人员：
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/)
 - [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
 <!--

content/en/_index.html

@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <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">Attend KubeCon NA virtually on November 17-20, 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</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">Attend KubeCon EU virtually on May 4 – 7, 2021</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Revisit KubeCon EU 2021</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md

@@ -95,7 +95,7 @@ The core workloads API surface is stable, but it’s still software, and softwar
 --Kenneth Owens, Software Engineer, Google  
 
 
-- [Download](http://get.k8s.io/) Kubernetes
+- [Download](https://get.k8s.io/) Kubernetes
 - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
 - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
 - Connect with the community on [Slack](http://slack.k8s.io/)

content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md

@@ -120,7 +120,7 @@ Run the following command to have Docker run the application in a container and
 ```
 docker run -p 5001:5000 hello-python
 ```
-Now navigate to http://localhost:5001, and you should see the “Hello form Python!” message. 
+Now navigate to http://localhost:5001, and you should see the “Hello from Python!” message. 
 
 ### More info
 * [Get started with Docker](https://docs.docker.com/get-started/)
@@ -201,7 +201,7 @@ kubectl get pods
 ```
 <img src="/images/blog/get-started-with-kubernetes-using-python/kubectl-get-pods.png" alt="Pod listing" />
 
-Now navigate to http://localhost:6000, and you should see the “Hello form Python!” message. 
+Now navigate to http://localhost:6000, and you should see the “Hello from Python!” message. 
 
 That’s it! The application is now running in Kubernetes!
 

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -526,6 +526,6 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves
 
 
 For background information on design details for API priority and fairness, see
-the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
+the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness).
 You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 
 or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -253,7 +253,7 @@ message AllocatableResourcesResponse {
 
 `ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine.
 The NUMA cells are identified using a opaque integer ID, which value is consistent to what device
-plugins report [when they register themselves to the kubelet](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).
+plugins report [when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).
 
 
 The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.

content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md

@@ -16,7 +16,7 @@ During a node-pressure eviction, the kubelet sets the `PodPhase` for the
 selected pods to `Failed`. This terminates the pods. 
 
 Node-pressure eviction is not the same as 
-[API-initiated eviction](/docs/concepts/scheduling-eviction/eviction/#api-eviction).
+[API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/).
 
 The kubelet does not respect your configured `PodDisruptionBudget` or the pod's
 `terminationGracePeriodSeconds`. If you use [soft eviction thresholds](#soft-eviction-thresholds),

content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -26,40 +26,41 @@ each resource to score nodes based on the request to capacity ratio. This
 allows users to bin pack extended resources by using appropriate parameters
 and improves the utilization of scarce resources in large clusters. The
 behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
-can be controlled by a configuration option called
+can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. 
-`requestedToCapacityRatioArguments`. This argument consists of two parameters
+This argument consists of two parameters `shape` and `resources`. The `shape` 
-`shape` and `resources`. The `shape` parameter allows the user to tune the
+parameter allows the user to tune the function as least requested or most 
-function as least requested or most requested based on `utilization` and
+requested based on `utilization` and `score` values.  The `resources` parameter 
-`score` values.  The `resources` parameter consists of `name` of the resource
+consists of `name` of the resource to be considered during scoring and `weight` 
-to be considered during scoring and `weight` specify the weight of each
+specify the weight of each resource.
-resource.
 
 Below is an example configuration that sets
 `requestedToCapacityRatioArguments` to bin packing behavior for extended
 resources `intel.com/foo` and `intel.com/bar`.
 
 ```yaml
-apiVersion: v1
+apiVersion: kubescheduler.config.k8s.io/v1beta1
-kind: Policy
+kind: KubeSchedulerConfiguration
+profiles:
 # ...
-priorities:
+  pluginConfig:
-  # ...
+  - name: RequestedToCapacityRatio
-  - name: RequestedToCapacityRatioPriority
+    args: 
-    weight: 2
+      shape:
-    argument:
+      - utilization: 0
-      requestedToCapacityRatioArguments:
+        score: 10
-        shape:
+      - utilization: 100
-          - utilization: 0
+        score: 0
-            score: 0
+      resources:
-          - utilization: 100
+      - name: intel.com/foo
-            score: 10
+        weight: 3
-        resources:
+      - name: intel.com/bar
-          - name: intel.com/foo
+        weight: 5
-            weight: 3
-          - name: intel.com/bar
-            weight: 5
 ```
 
+Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler 
+flag `--config=/path/to/config/file` will pass the configuration to the 
+scheduler.
+
 **This feature is disabled by default**
 
 ### Tuning the Priority Function

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

@@ -212,9 +212,9 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
 
 ## SCTP support
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
+As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
 When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
 
 {{< note >}}

content/en/docs/concepts/services-networking/topology-aware-hints.md

@@ -13,7 +13,7 @@ weight: 45
 
 _Topology Aware Hints_ enable topology aware routing by including suggestions
 for how clients should consume endpoints. This approach adds metadata to enable
-consumers of EndpointSlice and / or and Endpoints objects, so that traffic to
+consumers of EndpointSlice and / or Endpoints objects, so that traffic to
 those network endpoints can be routed closer to where it originated.
 
 For example, you can route traffic within a locality to reduce

content/en/docs/concepts/workloads/pods/disruptions.md

@@ -86,7 +86,7 @@ rolling out node software updates can cause voluntary disruptions. Also, some im
 of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
 Your cluster administrator or hosting provider should have documented what level of voluntary
 disruptions, if any, to expect. Certain configuration options, such as
-[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
+[using PriorityClasses](/docs/concepts/configuration/pod-priority-preemption/)
 in your pod spec can also cause voluntary (and involuntary) disruptions.
 
 

content/en/docs/contribute/analytics.md

@@ -0,0 +1,25 @@
+---
+title: Viewing Site Analytics
+content_type: concept
+weight: 100
+card:
+  name: contribute
+  weight: 100
+---
+
+<!-- overview -->
+
+This page contains information about the kubernetes.io analytics dashboard.
+
+
+<!-- body -->
+
+[View the dashboard](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04).
+
+This dashboard is built using Google Data Studio and shows information collected on kubernetes.io using Google Analytics.
+
+### Using the dashboard
+
+By default, the dashboard shows all collected analytics for the past 30 days. Use the date selector to see data from a different date range. Other filtering options allow you to view data based on user location, the device used to access the site, the translation of the docs used, and more.
+
+ If you notice an issue with this dashboard, or would like to request any improvements, please [open an issue](https://github.com/kubernetes/website/issues/new/choose).

content/en/docs/contribute/generate-ref-docs/contribute-upstream.md

@@ -134,7 +134,6 @@ Go to `<k8s-base>` and run these scripts:
 hack/update-generated-swagger-docs.sh
 hack/update-openapi-spec.sh
 hack/update-generated-protobuf.sh
-hack/update-api-reference-docs.sh
 ```
 
 Run `git status` to see what was generated.
@@ -143,8 +142,6 @@ Run `git status` to see what was generated.
 On branch master
 ...
     modified:   api/openapi-spec/swagger.json
-    modified:   api/swagger-spec/apps_v1.json
-    modified:   docs/api-reference/apps/v1/definitions.html
     modified:   staging/src/k8s.io/api/apps/v1/generated.proto
     modified:   staging/src/k8s.io/api/apps/v1/types.go
     modified:   staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go

content/en/docs/reference/_index.md

@@ -38,7 +38,7 @@ client libraries:
 - [Kubernetes Python client library](https://github.com/kubernetes-client/python)
 - [Kubernetes Java client library](https://github.com/kubernetes-client/java)
 - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
-- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp)
+- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp)
 - [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)
 
 ## CLI

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

@@ -58,7 +58,7 @@ It acts synchronously to modify pods as they are created or updated. When this p
 1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
 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.
-1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
+1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` of the `ServiceAccount` are added to the pod.
 
 #### Bound Service Account Token Volume
 
@@ -91,14 +91,14 @@ add the following projected volume instead of a Secret-based volume for the non-
 This projected volume consists of three sources:
 
 1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience.
-1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate being enabled, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` is enabled by default in 1.20, and always enabled in 1.21+.
+1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from --feature-gate arg in 1.22)
 1. A DownwardAPI that references the namespace of the pod.
 
 See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
 
-You can manually migrate a secret-based service account volume to a projected volume when
+You can manually migrate a Secret-based service account volume to a projected volume when
 the `BoundServiceAccountTokenVolume` feature gate is not enabled by adding the above
-projected volume to the pod spec. However, `RootCAConfigMap` needs to be enabled.
+projected volume to the pod spec.
 
 ### Token Controller
 

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -844,7 +844,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ValidateProxyRedirects`: This flag controls whether the API server should
   validate that redirects are only followed to the same host. Only used if the
   `StreamingProxyRedirects` flag is enabled.
-- 'VolumeCapacityPriority`: Enable support for prioritizing nodes in different
+- `VolumeCapacityPriority`: Enable support for prioritizing nodes in different
   topologies based on available PV capacity.
 - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
 - `VolumeScheduling`: Enable volume topology aware scheduling and make the

content/en/docs/reference/command-line-tools-reference/kube-apiserver.md

@@ -64,7 +64,7 @@ kube-apiserver [flags]
 <td colspan="2">--allow-metric-labels stringToString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is <!-- raw HTML omitted -->,<!-- raw HTML omitted -->. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is &lt;MetricName&gt;,&lt;LabelName&gt;. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
 </tr>
 
 <tr>
@@ -967,7 +967,7 @@ kube-apiserver [flags]
 <td colspan="2">--runtime-config &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of key=value pairs that enable or disable built-in APIs. Supported options are:<br/>v1=true|false for the core API group<br/><!-- raw HTML omitted -->/<!-- raw HTML omitted -->=true|false for a specific API group and version (e.g. apps/v1=true)<br/>api/all=true|false controls all API versions<br/>api/ga=true|false controls all API versions of the form v[0-9]+<br/>api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+<br/>api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+<br/>api/legacy is deprecated, and will be removed in a future version</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of key=value pairs that enable or disable built-in APIs. Supported options are:<br/>v1=true|false for the core API group<br/>&lt;group&gt;/&lt;version&gt;=true|false for a specific API group and version (e.g. apps/v1=true)<br/>api/all=true|false controls all API versions<br/>api/ga=true|false controls all API versions of the form v[0-9]+<br/>api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+<br/>api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+<br/>api/legacy is deprecated, and will be removed in a future version</p></td>
 </tr>
 
 <tr>
@@ -1044,7 +1044,7 @@ kube-apiserver [flags]
 <td colspan="2">--show-hidden-metrics-for-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <!-- raw HTML omitted -->.<!-- raw HTML omitted -->, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md

@@ -61,7 +61,7 @@ kube-controller-manager [flags]
 <td colspan="2">--allow-metric-labels stringToString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is <!-- raw HTML omitted -->,<!-- raw HTML omitted -->. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is &lt;MetricName&gt;,&lt;LabelName&gt;. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
 </tr>
 
 <tr>
@@ -943,7 +943,7 @@ kube-controller-manager [flags]
 <td colspan="2">--show-hidden-metrics-for-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <!-- raw HTML omitted -->.<!-- raw HTML omitted -->, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/command-line-tools-reference/kube-proxy.md

@@ -424,7 +424,7 @@ kube-proxy [flags]
 <td colspan="2">--show-hidden-metrics-for-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <!-- raw HTML omitted -->.<!-- raw HTML omitted -->, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/command-line-tools-reference/kube-scheduler.md

@@ -27,7 +27,7 @@ each Pod in the scheduling queue according to constraints and available
 resources. The scheduler then ranks each valid Node and binds the Pod to a
 suitable Node. Multiple different schedulers may be used within a cluster;
 kube-scheduler is the reference implementation.
-See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
+See [scheduling](/docs/concepts/scheduling-eviction/)
 for more information about scheduling and the kube-scheduler component.
 
 ```
@@ -68,7 +68,7 @@ kube-scheduler [flags]
 <td colspan="2">--allow-metric-labels stringToString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is <!-- raw HTML omitted -->,<!-- raw HTML omitted -->. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The map from metric-label to value allow-list of this label. The key's format is &lt;MetricName&gt;,&lt;LabelName&gt;. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.</p></td>
 </tr>
 
 <tr>
@@ -474,7 +474,7 @@ kube-scheduler [flags]
 <td colspan="2">--show-hidden-metrics-for-version string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <!-- raw HTML omitted -->.<!-- raw HTML omitted -->, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/labels-annotations-taints.md

@@ -222,7 +222,9 @@ When a single IngressClass resource has this annotation set to `"true"`, new Ing
 
 ## kubernetes.io/ingress.class (deprecated)
 
-{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}}
+{{< note >}}
+Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`.
+{{< /note >}}
 
 ## storageclass.kubernetes.io/is-default-class
 
@@ -230,7 +232,8 @@ Example: `storageclass.kubernetes.io/is-default-class=true`
 
 Used on: StorageClass
 
-When a single StorageClass resource has this annotation set to `"true"`, new Physical Volume Claim resource without a class specified will be assigned this default class.
+When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim
+resource without a class specified will be assigned this default class.
 
 ## alpha.kubernetes.io/provided-node-ip
 

content/en/docs/reference/scheduling/config.md

@@ -250,7 +250,7 @@ only has one pending pods queue.
 
 ## {{% heading "whatsnext" %}}
 
-* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
+* Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/)
 * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
 * Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
 

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md

@@ -17,7 +17,7 @@ Generate keys and certificate signing requests
 
 Generates keys and certificate signing requests (CSRs) for all the certificates required to run the control plane. This command also generates partial kubeconfig files with private key data in the  "users > user > client-key-data" field, and for each kubeconfig file an accompanying ".csr" file is created.
 
-This command is designed for use in [Kubeadm External CA Mode](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing.
+This command is designed for use in [Kubeadm External CA Mode](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing.
 
 The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users > user > client-certificate-data" field.
 

content/en/docs/reference/using-api/api-concepts.md

@@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path
 * Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
 * Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
 
-The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
+The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
 
 
 ## Efficient detection of changes
@@ -442,7 +442,7 @@ feature, see the section on
 
 ## Resource Versions
 
-Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
+Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
 
 ### ResourceVersion in metadata
 
@@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev
 
 ### The ResourceVersion Parameter
 
-The get, list and watch operations support the `resourceVersion` parameter.
+The get, list, and watch operations support the `resourceVersion` parameter.
 
 The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.
 

content/en/docs/reference/using-api/deprecation-guide.md

@@ -74,7 +74,7 @@ The **policy/v1beta1** API version of PodDisruptionBudget will no longer be serv
 PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed.
 
 PodSecurityPolicy replacements are still under discussion, but current use can be migrated to
-[3rd-party admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) now.
+[3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now.
 
 #### RuntimeClass {#runtimeclass-v125}
 

content/en/docs/reference/using-api/server-side-apply.md

@@ -245,7 +245,7 @@ field tags.
 
 ### Compatibility across topology changes
 
-On rare occurences, a CRD or built-in type author may want to change the
+On rare occurrences, a CRD or built-in type author may want to change the
 specific topology of a field in their resource without incrementing its
 version. Changing the topology of types, by upgrading the cluster or
 updating the CRD, has different consequences when updating existing
@@ -253,7 +253,7 @@ objects. There are two categories of changes: when a field goes from
 `map`/`set`/`granular` to `atomic` and the other way around.
 
 When the `listType`, `mapType`, or `structType` changes from
-`map`/`set`/`granular` to `atomic`, the whole list, map or struct of
+`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of
 existing objects will end-up being owned by actors who owned an element
 of these types. This means that any further change to these objects
 would cause a conflict.
@@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a
 read-modify-write and/or patch are the following:
 
 * the applied object must contain all the fields that the controller cares about.
-* there are no way to remove fields that haven't been applied by the controller
+* there is no way to remove fields that haven't been applied by the controller
   before (controller can still send a PATCH/UPDATE for these use-cases).
 * the object doesn't have to be read beforehand, `resourceVersion` doesn't have
   to be specified.
@@ -473,7 +473,7 @@ have an opinion about.
 ## Clearing ManagedFields
 
 It is possible to strip all managedFields from an object by overwriting them
-using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every
 non-apply operation. This can be done by overwriting the managedFields field
 with an empty entry. Two examples are:
 

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

@@ -66,8 +66,8 @@ When creating a cluster, you can (using custom tooling):
 * start and configure additional etcd instance
 * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events
 
-See [Operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) and
+See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and
-[Set up a High Availability etcd cluster with kubeadm](docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
+[Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
 for details on configuring and managing etcd for a large cluster.
 
 ## Addon resources

content/en/docs/setup/production-environment/_index.md

@@ -49,7 +49,7 @@ access cluster resources. You can use role-based access control
 security mechanisms to make sure that users and workloads can get access to the
 resources they need, while keeping workloads, and the cluster itself, secure.
 You can set limits on the resources that users and workloads can access
-by managing [policies](https://kubernetes.io/docs/concepts/policy/) and
+by managing [policies](/docs/concepts/policy/) and
 [container resources](/docs/concepts/configuration/manage-resources-containers/).
 
 Before building a Kubernetes production environment on your own, consider
@@ -286,8 +286,8 @@ and the
 deployment methods.
 - Configure user management by determining your
 [Authentication](/docs/reference/access-authn-authz/authentication/) and
-[Authorization](docs/reference/access-authn-authz/authorization/) methods.
+[Authorization](/docs/reference/access-authn-authz/authorization/) methods.
 - Prepare for application workloads by setting up
-[resource limits](docs/tasks/administer-cluster/manage-resources/),
+[resource limits](/docs/tasks/administer-cluster/manage-resources/),
 [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
 and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/).

content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md

@@ -23,7 +23,7 @@ of Containers for each.
 
 - Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
 - Format the output to include only the list of Container image names
-  using `-o jsonpath={..image}`.  This will recursively parse out the
+  using `-o jsonpath={.items[*].spec.containers[*].image}`.  This will recursively parse out the
   `image` field from the returned json.
   - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/)
     for further information on how to use jsonpath.
@@ -33,7 +33,7 @@ of Containers for each.
   - Use `uniq` to aggregate image counts
 
 ```shell
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag.  The
 following matches only Pods with labels matching `app=nginx`.
 
 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```
 
 ## List Container images filtering by Pod namespace
@@ -89,7 +89,7 @@ To target only pods in a specific namespace, use the namespace flag. The
 following matches only Pods in the `kube-system` namespace.
 
 ```shell
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 
 ## List Container images using a go-template instead of jsonpath

content/en/docs/tasks/administer-cluster/highly-available-control-plane.md

@@ -1,16 +1,17 @@
 ---
 reviewers:
 - jszczepkowski
-title: Set up High-Availability Kubernetes Masters
+title: Set up a High-Availability Control Plane
 content_type: task
+aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ]
 ---
 
 <!-- overview -->
 
 {{< feature-state for_k8s_version="v1.5" state="alpha" >}}
 
-You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
+You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine.
-This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
+This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE.
 
 
 
@@ -28,17 +29,17 @@ This document describes how to use kube-up/down scripts to manage highly availab
 
 To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
 
-* `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone.
+* `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone.
-Required if you want to run master replicas in different zones, which is recommended.
+Required if you want to run control plane nodes in different zones, which is recommended.
 
 * `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data.
 If true, reads will be directed to leader etcd replica.
 Setting this value to true is optional: reads will be more reliable but will also be slower.
 
-Optionally, you can specify a GCE zone where the first master replica is to be created.
+Optionally, you can specify a GCE zone where the first control plane node is to be created.
 Set the following flag:
 
-* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run.
+* `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run.
 
 The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
 
@@ -46,50 +47,52 @@ The following sample command sets up a HA-compatible cluster in the GCE zone eur
 MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
 ```
 
-Note that the commands above create a cluster with one master;
+Note that the commands above create a cluster with one control plane node;
-however, you can add new master replicas to the cluster with subsequent commands.
+however, you can add new control plane nodes to the cluster with subsequent commands.
 
-## Adding a new master replica
+## Adding a new control plane node
 
-After you have created an HA-compatible cluster, you can add master replicas to it.
+After you have created an HA-compatible cluster, you can add control plane nodes to it.
-You add master replicas by using a `kube-up` script with the following flags:
+You add control plane nodes by using a `kube-up` script with the following flags:
 
-* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane
-master.
+node.
 
-* `KUBE_GCE_ZONE=zone` - zone where the master replica will run.
+* `KUBE_GCE_ZONE=zone` - zone where the control plane node will run.
-Must be in the same region as other replicas' zones.
+Must be in the same region as other control plane nodes' zones.
 
 You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags,
 as those are inherited from when you started your HA-compatible cluster.
 
-The following sample command replicates the master on an existing HA-compatible cluster:
+The following sample command replicates the control plane node on an existing
+HA-compatible cluster:
 
 ```shell
 KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 
-## Removing a master replica
+## Removing a control plane node
 
-You can remove a master replica from an HA cluster by using a `kube-down` script with the following flags:
+You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags:
 
 * `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets.
 
-* `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed.
+* `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed.
 
-* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove.
+* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to
-If empty: any replica from the given zone will be removed.
+remove. If empty: any replica from the given zone will be removed.
 
-The following sample command removes a master replica from an existing HA cluster:
+The following sample command removes a control plane node from an existing HA cluster:
 
 ```shell
 KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ```
 
-## Handling master replica failures
+## Handling control plane node failures
 
-If one of the master replicas in your HA cluster fails,
+If one of the control plane nodes in your HA cluster fails,
-the best practice is to remove the replica from your cluster and add a new replica in the same zone.
+the best practice is to remove the node from your cluster and add a new control plane
+node in the same zone.
 The following sample commands demonstrate this process:
 
 1. Remove the broken replica:
@@ -98,26 +101,31 @@ The following sample commands demonstrate this process:
 KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
 ```
 
-<ol start="2"><li>Add a new replica in place of the old one:</li></ol>
+<ol start="2"><li>Add a new node in place of the old one:</li></ol>
 
 ```shell
 KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 
-## Best practices for replicating masters for HA clusters
+## Best practices for replicating control plane nodes for HA clusters
 
-* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail.
+* Try to place control plane nodes in different zones. During a zone failure, all
+control plane nodes placed inside the zone will fail.
 To survive zone failure, also place nodes in multiple zones
 (see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details).
 
-* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state.
+* Do not use a cluster with two control plane nodes. Consensus on a two-node
-As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
+control plane requires both nodes running when changing persistent state.
-A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster.
+As a result, both nodes are needed and a failure of any node turns the cluster
+into majority failure state.
+A two-node control plane is thus inferior, in terms of HA, to a cluster with
+one control plane node.
 
-* When you add a master replica, cluster state (etcd) is copied to a new instance.
+* When you add a control plane node, cluster state (etcd) is copied to a new instance.
 If the cluster is large, it may take a long time to duplicate its state.
-This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
+This operation may be sped up by migrating the etcd data directory, as described in
-(we are considering adding support for etcd data dir migration in future).
+the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration)
+(we are considering adding support for etcd data dir migration in the future).
 
 
 
@@ -129,7 +137,7 @@ This operation may be sped up by migrating etcd data directory, as described [he
 
 ### Overview
 
-Each of master replicas will run the following components in the following mode:
+Each of the control plane nodes will run the following components in the following mode:
 
 * etcd instance: all instances will be clustered together using consensus;
 
@@ -143,9 +151,9 @@ In addition, there will be a load balancer in front of API servers that will rou
 
 ### Load balancing
 
-When starting the second master replica, a load balancer containing the two replicas will be created
+When starting the second control plane node, a load balancer containing the two replicas will be created
 and the IP address of the first replica will be promoted to IP address of load balancer.
-Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
+Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
 Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
 
 ### Master service & kubelets
@@ -153,17 +161,17 @@ Please note that creation and removal of load balancer are complex operations an
 Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
 the system directs all traffic to the external IP:
 
-* in one master cluster the IP points to the single master,
+* in case of a single node control plane, the IP points to the control plane node,
 
-* in multi-master cluster the IP points to the load balancer in-front of the masters.
+* in case of an HA control plane, the IP points to the load balancer in-front of the masters.
 
-Similarly, the external IP will be used by kubelets to communicate with master.
+Similarly, the external IP will be used by kubelets to communicate with the control plane.
 
-### Master certificates
+### Control plane node certificates
 
-Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica.
+Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node.
-There are no certificates for the ephemeral public IP for replicas;
+There are no certificates for the ephemeral public IP for control plane nodes;
-to access a replica via its ephemeral public IP, you must skip TLS verification.
+to access a control plane node via its ephemeral public IP, you must skip TLS verification.
 
 ### Clustering etcd
 
@@ -172,7 +180,7 @@ To make such deployment secure, communication between etcd instances is authoriz
 
 ### API server identity
 
-{{< feature-state state="alpha"  for_k8s_version="v1.20" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
 
 The API Server Identity feature is controlled by a
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)

content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md

@@ -188,7 +188,7 @@ To install a specific version of containerD specify the version with -ContainerD
 
 ```powershell
 # Example
-.\Install-Containerd.ps1 -ContainerDVersion v1.4.1
+.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
 ```
 
 {{< /note >}}

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -239,7 +239,7 @@ The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet servin
 certificates by requesting them from the `certificates.k8s.io` API. One known limitation
 is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically
 approved by the default signer in the kube-controller-manager -
-[`kubernetes.io/kubelet-serving`](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers).
+[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers).
 This will require action from the user or a third party controller.
 
 These CSRs can be viewed using:

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

@@ -167,8 +167,8 @@ The output is similar to this:
 Name:           build-robot-secret
 Namespace:      default
 Labels:         <none>
-Annotations:    kubernetes.io/service-account.name=build-robot
+Annotations:    kubernetes.io/service-account.name: build-robot
-                kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
+                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da
 
 Type:   kubernetes.io/service-account-token
 

content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md

@@ -54,7 +54,7 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr
 
 ## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials}
 
-A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with
+A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with
 a container registry to pull a private image.
 
 If you already ran `docker login`, you can copy that credential into Kubernetes:

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

@@ -45,8 +45,12 @@ kubectl create namespace qos-example
 
 For a Pod to be given a QoS class of Guaranteed:
 
-* 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 memory limit and a memory request.
-* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* For every Container in the Pod, the memory limit must equal the memory request.
+* Every Container in the Pod must have a CPU limit and a CPU request.
+* For every Container in the Pod, the CPU limit must equal the CPU request.
+
+These restrictions apply to init containers and app containers equally.
 
 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:
@@ -272,5 +276,3 @@ kubectl delete namespace qos-example
 
 
 
-
-

content/en/docs/tasks/configure-pod-container/security-context.md

@@ -176,7 +176,6 @@ securityContext:
   fsGroupChangePolicy: "OnRootMismatch"
 ```
 
-This is an alpha feature. To use it, enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ConfigurableFSGroupPolicy` for the kube-api-server, the kube-controller-manager, and for the kubelet.
 
 {{< note >}}
 This field has no effect on ephemeral volume types such as

content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md

@@ -1,371 +0,0 @@
----
-reviewers:
-- piosz
-- x13n
-title: Logging Using Stackdriver
-content_type: concept
----
-
-<!-- overview -->
-
-Before reading this page, it's highly recommended to familiarize yourself
-with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
-
-{{< note >}}
-By default, Stackdriver logging collects only your container's standard output and
-standard error streams. To collect any logs your application writes to a file (for example),
-see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
-in the Kubernetes logging overview.
-{{< /note >}}
-
-
-
-
-<!-- body -->
-
-## Deploying
-
-To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster.
-The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap`
-and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the
-`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup.
-
-### Deploying to a new cluster
-
-#### Google Kubernetes Engine
-
-Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine.
-Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out.
-
-#### Other platforms
-
-To deploy Stackdriver Logging on a *new* cluster that you're
-creating using `kube-up.sh`, do the following:
-
-1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`.
-1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true`
-in the `KUBE_NODE_LABELS` variable.
-
-Once your cluster has started, each node should be running the Stackdriver Logging agent.
-The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`,
-consider starting a cluster without a pre-configured logging solution and then deploying
-Stackdriver Logging agents to the running cluster.
-
-{{< warning >}}
-The Stackdriver logging daemon has known issues on platforms other
-than Google Kubernetes Engine. Proceed at your own risk.
-{{< /warning >}}
-
-### Deploying to an existing cluster
-
-1. Apply a label on each node, if not already present.
-
-    The Stackdriver Logging agent deployment uses node labels to determine to which nodes
-    it should be allocated. These labels were introduced to distinguish nodes with the
-    Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging
-    configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node
-    cannot have more than one instance of fluentd, therefore only apply labels to the nodes
-    that don't have fluentd pod allocated already. You can ensure that your node is labelled
-    properly by running `kubectl describe` as follows:
-
-    ```
-    kubectl describe node $NODE_NAME
-    ```
-
-    The output should be similar to this:
-
-    ```
-    Name:           NODE_NAME
-    Role:
-    Labels:         beta.kubernetes.io/fluentd-ds-ready=true
-    ...
-    ```
-
-    Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it
-    is not present, you can add it using the `kubectl label` command as follows:
-
-    ```
-    kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
-    ```
-
-    {{< note >}}
-    If a node fails and has to be recreated, you must re-apply the label to
-    the recreated node. To make this easier, you can use Kubelet's command-line parameter
-    for applying node labels in your node startup script.
-    {{< /note >}}
-
-1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
-
-    ```
-    kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml
-    ```
-
-    The command creates the `ConfigMap` in the `default` namespace. You can download the file
-    manually and change it before creating the `ConfigMap` object.
-
-1. Deploy the logging agent `DaemonSet` by running the following command:
-
-    ```
-    kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml
-    ```
-
-    You can download and edit this file before using it as well.
-
-## Verifying your Logging Agent Deployment
-
-After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status
-by running the following command:
-
-```shell
-kubectl get ds --all-namespaces
-```
-
-If you have 3 nodes in the cluster, the output should looks similar to this:
-
-```
-NAMESPACE     NAME               DESIRED   CURRENT   READY     NODE-SELECTOR                              AGE
-...
-default       fluentd-gcp-v2.0   3         3         3         beta.kubernetes.io/fluentd-ds-ready=true   5m
-...
-```
-
-To understand how logging with Stackdriver works, consider the following
-synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml):
-
-{{< codenew file="debug/counter-pod.yaml" >}}
-
-This pod specification has one container that runs a bash script
-that writes out the value of a counter and the datetime once per
-second, and runs indefinitely. Let's create this pod in the default namespace.
-
-```shell
-kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
-```
-
-You can observe the running pod:
-
-```shell
-kubectl get pods
-```
-```
-NAME                                           READY     STATUS    RESTARTS   AGE
-counter                                        1/1       Running   0          5m
-```
-
-For a short period of time you can observe the 'Pending' pod status, because the kubelet
-has to download the container image first. When the pod status changes to `Running`
-you can use the `kubectl logs` command to view the output of this counter pod.
-
-```shell
-kubectl logs counter
-```
-```
-0: Mon Jan  1 00:00:00 UTC 2001
-1: Mon Jan  1 00:00:01 UTC 2001
-2: Mon Jan  1 00:00:02 UTC 2001
-...
-```
-
-As described in the logging overview, this command fetches log entries
-from the container log file. If the container is killed and then restarted by
-Kubernetes, you can still access logs from the previous container. However,
-if the pod is evicted from the node, log files are lost. Let's demonstrate this
-by deleting the currently running counter container:
-
-```shell
-kubectl delete pod counter
-```
-```
-pod "counter" deleted
-```
-
-and then recreating it:
-
-```shell
-kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
-```
-```
-pod/counter created
-```
-
-After some time, you can access logs from the counter pod again:
-
-```shell
-kubectl logs counter
-```
-```
-0: Mon Jan  1 00:01:00 UTC 2001
-1: Mon Jan  1 00:01:01 UTC 2001
-2: Mon Jan  1 00:01:02 UTC 2001
-...
-```
-
-As expected, only recent log lines are present. However, for a real-world
-application you will likely want to be able to access logs from all containers,
-especially for the debug purposes. This is exactly when the previously enabled
-Stackdriver Logging can help.
-
-## Viewing logs
-
-Stackdriver Logging agent attaches metadata to each log entry, for you to use later
-in queries to select only the messages you're interested in: for example,
-the messages from a particular pod.
-
-The most important pieces of metadata are the resource type and log name.
-The resource type of a container log is `container`, which is named
-`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine).
-The log name is the name of the container, so that if you have a pod with
-two containers, named `container_1` and `container_2` in the spec, their logs
-will have log names `container_1` and `container_2` respectively.
-
-System components have resource type `compute`, which is named
-`GCE VM Instance` in the interface. Log names for system components are fixed.
-For a Google Kubernetes Engine node, every log entry from a system component has one of the following
-log names:
-
-* docker
-* kubelet
-* kube-proxy
-
-You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
-
-One of the possible ways to view logs is using the
-[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
-command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/).
-It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
-to query specific logs. For example, you can run the following command:
-
-```none
-gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
-```
-```
-...
-"2: Mon Jan  1 00:01:02 UTC 2001\n"
-"1: Mon Jan  1 00:01:01 UTC 2001\n"
-"0: Mon Jan  1 00:01:00 UTC 2001\n"
-...
-"2: Mon Jan  1 00:00:02 UTC 2001\n"
-"1: Mon Jan  1 00:00:01 UTC 2001\n"
-"0: Mon Jan  1 00:00:00 UTC 2001\n"
-```
-
-As you can see, it outputs messages for the count container from both
-the first and second runs, despite the fact that the kubelet already deleted
-the logs for the first container.
-
-### Exporting logs
-
-You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
-or to [BigQuery](https://cloud.google.com/bigquery/) to run further
-analysis. Stackdriver Logging offers the concept of sinks, where you can
-specify the destination of log entries. More information is available on
-the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
-
-## Configuring Stackdriver Logging Agents
-
-Sometimes the default installation of Stackdriver Logging may not suit your needs, for example:
-
-* You may want to add more resources because default performance doesn't suit your needs.
-* You may want to introduce additional parsing to extract more metadata from your log messages,
-like severity or source code reference.
-* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially.
-
-In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`.
-
-### Prerequisites
-
-If you're using GKE and Stackdriver Logging is enabled in your cluster, you
-cannot change its configuration, because it's managed and supported by GKE.
-However, you can disable the default integration and deploy your own.
-
-{{< note >}}
-You will have to support and maintain a newly deployed configuration
-yourself: update the image and configuration, adjust the resources and so on.
-{{< /note >}}
-
-To disable the default logging integration, use the following command:
-
-```
-gcloud beta container clusters update --logging-service=none CLUSTER
-```
-
-You can find notes on how to then install Stackdriver Logging agents into
-a running cluster in the [Deploying section](#deploying).
-
-### Changing `DaemonSet` parameters
-
-When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the
-`template` field in its spec. The DaemonSet controller manages the pods for you.
-For example, assume you've installed the Stackdriver Logging as described above. Now you want to
-change the memory limit to give fluentd more memory to safely process more logs.
-
-Get the spec of `DaemonSet` running in your cluster:
-
-```shell
-kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml
-```
-
-Then edit resource requirements in the spec file and update the `DaemonSet` object
-in the apiserver using the following command:
-
-```shell
-kubectl replace -f fluentd-gcp-ds.yaml
-```
-
-After some time, Stackdriver Logging agent pods will be restarted with the new configuration.
-
-### Changing fluentd parameters
-
-Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
-files that are merged together. You can learn about fluentd configuration on the
-[official site](https://docs.fluentd.org).
-
-Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
-default Python logging format. An appropriate fluentd filter looks similar to this:
-
-```
-<filter reform.**>
-  type parser
-  format /^(?<severity>\w):(?<logger_name>\w):(?<log>.*)/
-  reserve_data true
-  suppress_parse_error_log true
-  key_name log
-</filter>
-```
-
-Now you have to put it in the configuration and make Stackdriver Logging agents pick it up.
-Get the current version of the Stackdriver Logging `ConfigMap` in your cluster
-by running the following command:
-
-```shell
-kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml
-```
-
-Then in the value of the key `containers.input.conf` insert a new filter right after
-the `source` section.
-
-{{< note >}}
-Order is important.
-{{< /note >}}
-
-Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
-to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
-create `ConfigMap` with a new name and then change `DaemonSet` to point to it
-using [guide above](#changing-daemonset-parameters).
-
-### Adding fluentd plugins
-
-Fluentd is written in Ruby and allows to extend its capabilities using
-[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
-in the default Stackdriver Logging container image, you have to build a custom image. Imagine
-you want to add Kafka sink for messages from a particular container for additional processing.
-You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
-with minor changes:
-
-* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
-* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
-
-Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
-new image, you can use the plugin you installed in the fluentd configuration.
-
-

content/en/docs/tasks/tools/install-kubectl-macos.md

@@ -31,6 +31,7 @@ The following methods exist for installing kubectl on macOS:
    {{< tabs name="download_binary_macos" >}}
    {{< tab name="Intel" codelang="bash" >}}
    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
+   chmod +x kubectl
    {{< /tab >}}
    {{< tab name="Apple Silicon" codelang="bash" >}}
    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"

content/en/releases/patch-releases.md

@@ -10,10 +10,10 @@ For general information about Kubernetes release cycle, see the
 
 ## Cadence
 
-Our typical patch release cadence is monthly.  It is
+Our typical patch release cadence is monthly. It is
 commonly a bit faster (1 to 2 weeks) for the earliest patch releases
-after a 1.X minor release.  Critical bug fixes may cause a more
+after a 1.X minor release. Critical bug fixes may cause a more
-immediate release outside of the normal cadence.  We also aim to not make
+immediate release outside of the normal cadence. We also aim to not make
 releases during major holiday periods.
 
 ## Contact
@@ -23,7 +23,7 @@ See the [Release Managers page][release-managers] for full contact details on th
 Please give us a business day to respond - we may be in a different timezone!
 
 In between releases the team is looking at incoming cherry pick
-requests on a weekly basis.  The team will get in touch with
+requests on a weekly basis. The team will get in touch with
 submitters via GitHub PR, SIG channels in Slack, and direct messages
 in Slack and [email](mailto:release-managers-private@kubernetes.io)
 if there are questions on the PR.
@@ -34,8 +34,8 @@ Please follow the [cherry pick process][cherry-picks].
 
 Cherry picks must be merge-ready in GitHub with proper labels (e.g.,
 `approved`, `lgtm`, `release-note`) and passing CI tests ahead of the
-cherry pick deadline.  This is typically two days before the target
+cherry pick deadline. This is typically two days before the target
-release, but may be more.  Earlier PR readiness is better, as we
+release, but may be more. Earlier PR readiness is better, as we
 need time to get CI signal after merging your cherry picks ahead
 of the actual release.
 
@@ -73,15 +73,15 @@ dates for simplicity (every month has it).
 ## Upcoming Monthly Releases
 
 Timelines may vary with the severity of bug fixes, but for easier planning we
-will target the following monthly release points.  Unplanned, critical
+will target the following monthly release points. Unplanned, critical
 releases may also occur in between these.
 
 | Monthly Patch Release | Target date |
-| --- | --- |
+| --------------------- | ----------- |
-| June 2021 | 2021-06-16 |
+| June 2021             | 2021-06-16  |
-| July 2021 | 2021-07-14 |
+| July 2021             | 2021-07-14  |
-| August 2021 | 2021-08-11 |
+| August 2021           | 2021-08-11  |
-| September 2021 | 2021-09-15 |
+| September 2021        | 2021-09-15  |
 
 ## Detailed Release History for Active Branches
 
@@ -92,7 +92,7 @@ releases may also occur in between these.
 End of Life for **1.21** is **2022-06-28**
 
 | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
-|--- |--- |--- |
+| ------------- | -------------------- | ----------- |
 | 1.21.2        | 2021-06-12           | 2021-06-16  |
 | 1.21.1        | 2021-05-07           | 2021-05-12  |
 
@@ -102,16 +102,16 @@ End of Life for **1.21** is **2022-06-28**
 
 End of Life for **1.20** is **2022-02-28**
 
-| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
+| PATCH RELEASE | CHERRY PICK DEADLINE                                                                | TARGET DATE |
-|--- |--- |--- |
+| ------------- | ----------------------------------------------------------------------------------- | ----------- |
-| 1.20.8        | 2021-06-12           | 2021-06-16  |
+| 1.20.8        | 2021-06-12                                                                          | 2021-06-16  |
-| 1.20.7        | 2021-05-07           | 2021-05-12  |
+| 1.20.7        | 2021-05-07                                                                          | 2021-05-12  |
-| 1.20.6        | 2021-04-09           | 2021-04-14  |
+| 1.20.6        | 2021-04-09                                                                          | 2021-04-14  |
-| 1.20.5        | 2021-03-12           | 2021-03-17  |
+| 1.20.5        | 2021-03-12                                                                          | 2021-03-17  |
-| 1.20.4        | 2021-02-12           | 2021-02-18  |
+| 1.20.4        | 2021-02-12                                                                          | 2021-02-18  |
 | 1.20.3        | [Conformance Tests Issue](https://groups.google.com/g/kubernetes-dev/c/oUpY9vWgzJo) | 2021-02-17  |
-| 1.20.2        | 2021-01-08           | 2021-01-13  |
+| 1.20.2        | 2021-01-08                                                                          | 2021-01-13  |
-| 1.20.1        | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18  |
+| 1.20.1        | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA)           | 2020-12-18  |
 
 ### 1.19
 
@@ -119,46 +119,46 @@ End of Life for **1.20** is **2022-02-28**
 
 End of Life for **1.19** is **2021-10-28**
 
-| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
+| PATCH RELEASE | CHERRY PICK DEADLINE                                                      | TARGET DATE |
-|--- |--- |--- |
+| ------------- | ------------------------------------------------------------------------- | ----------- |
-| 1.19.12       | 2021-06-12           | 2021-06-16  |
+| 1.19.12       | 2021-06-12                                                                | 2021-06-16  |
-| 1.19.11       | 2021-05-07           | 2021-05-12  |
+| 1.19.11       | 2021-05-07                                                                | 2021-05-12  |
-| 1.19.10       | 2021-04-09           | 2021-04-14  |
+| 1.19.10       | 2021-04-09                                                                | 2021-04-14  |
-| 1.19.9        | 2021-03-12           | 2021-03-17  |
+| 1.19.9        | 2021-03-12                                                                | 2021-03-17  |
-| 1.19.8        | 2021-02-12           | 2021-02-17  |
+| 1.19.8        | 2021-02-12                                                                | 2021-02-17  |
-| 1.19.7        | 2021-01-08           | 2021-01-13  |
+| 1.19.7        | 2021-01-08                                                                | 2021-01-13  |
 | 1.19.6        | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18  |
-| 1.19.5        | 2020-12-04           | 2020-12-09  |
+| 1.19.5        | 2020-12-04                                                                | 2020-12-09  |
-| 1.19.4        | 2020-11-06           | 2020-11-11  |
+| 1.19.4        | 2020-11-06                                                                | 2020-11-11  |
-| 1.19.3        | 2020-10-09           | 2020-10-14  |
+| 1.19.3        | 2020-10-09                                                                | 2020-10-14  |
-| 1.19.2        | 2020-09-11           | 2020-09-16  |
+| 1.19.2        | 2020-09-11                                                                | 2020-09-16  |
-| 1.19.1        | 2020-09-04           | 2020-09-09  |
+| 1.19.1        | 2020-09-04                                                                | 2020-09-09  |
 
 ## Non-Active Branch History
 
 These releases are no longer supported.
 
-| Minor Version | Final Patch Release | EOL date |
+| Minor Version | Final Patch Release | EOL date   |
-| --- | --- | --- |
+| ------------- | ------------------- | ---------- |
-| 1.18 | 1.18.19 | 2021-05-12 |
+| 1.18          | 1.18.19             | 2021-05-12 |
-| 1.17 | 1.17.17 | 2021-01-13 |
+| 1.17          | 1.17.17             | 2021-01-13 |
-| 1.16 | 1.16.15 | 2020-09-02 |
+| 1.16          | 1.16.15             | 2020-09-02 |
-| 1.15 | 1.15.12 | 2020-05-06 |
+| 1.15          | 1.15.12             | 2020-05-06 |
-| 1.14 | 1.14.10 | 2019-12-11 |
+| 1.14          | 1.14.10             | 2019-12-11 |
-| 1.13 | 1.13.12 | 2019-10-15 |
+| 1.13          | 1.13.12             | 2019-10-15 |
-| 1.12 | 1.12.10 | 2019-07-08 |
+| 1.12          | 1.12.10             | 2019-07-08 |
-| 1.11 | 1.11.10 | 2019-05-01 |
+| 1.11          | 1.11.10             | 2019-05-01 |
-| 1.10 | 1.10.13 | 2019-02-13 |
+| 1.10          | 1.10.13             | 2019-02-13 |
-| 1.9  | 1.9.11  | 2018-09-29 |
+| 1.9           | 1.9.11              | 2018-09-29 |
-| 1.8  | 1.8.15  | 2018-07-12 |
+| 1.8           | 1.8.15              | 2018-07-12 |
-| 1.7  | 1.7.16  | 2018-04-04 |
+| 1.7           | 1.7.16              | 2018-04-04 |
-| 1.6  | 1.6.13  | 2017-11-23 |
+| 1.6           | 1.6.13              | 2017-11-23 |
-| 1.5  | 1.5.8   | 2017-10-01 |
+| 1.5           | 1.5.8               | 2017-10-01 |
-| 1.4  | 1.4.12  | 2017-04-21 |
+| 1.4           | 1.4.12              | 2017-04-21 |
-| 1.3  | 1.3.10  | 2016-11-01 |
+| 1.3           | 1.3.10              | 2016-11-01 |
-| 1.2  | 1.2.7   | 2016-10-23 |
+| 1.2           | 1.2.7               | 2016-10-23 |
 
-[cherry-picks]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md
+[cherry-picks]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
 [release-managers]: /release-managers.md
 [release process description]: /release.md
 [yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md

content/en/releases/release.md

@@ -3,6 +3,7 @@ title: Kubernetes Release Cycle
 type: docs
 auto_generated: true
 ---
+
 <!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/releng/update-release-info.sh in k/website -->
 
 {{< warning >}}
@@ -89,43 +90,43 @@ The general labeling process should be consistent across artifact types.
 
 ## Definitions
 
-- *issue owners*: Creator, assignees, and user who moved the issue into a
+- _issue owners_: Creator, assignees, and user who moved the issue into a
   release milestone
 
-- *Release Team*: Each Kubernetes release has a team doing project management
+- _Release Team_: Each Kubernetes release has a team doing project management
   tasks described [here][release-team].
 
   The contact info for the team associated with any given release can be found
   [here](https://git.k8s.io/sig-release/releases/).
 
-- *Y days*: Refers to business days
+- _Y days_: Refers to business days
 
-- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)"
+- _enhancement_: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)"
 
-- *[Enhancements Freeze][enhancements-freeze]*:
+- _[Enhancements Freeze][enhancements-freeze]_:
   the deadline by which [KEPs][keps] have to be completed in order for
   enhancements to be part of the current release
 
-- *[Exception Request][exceptions]*:
+- _[Exception Request][exceptions]_:
   The process of requesting an extension on the deadline for a particular
   Enhancement
 
-- *[Code Freeze][code-freeze]*:
+- _[Code Freeze][code-freeze]_:
   The period of ~4 weeks before the final release date, during which only
   critical bug fixes are merged into the release.
 
-- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*:
+- _[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)_:
   The process of removing an Enhancement from a release milestone if it is not
   fully implemented or is otherwise considered not stable.
 
-- *release milestone*: semantic version string or
+- _release milestone_: semantic version string or
   [GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
   referring to a release MAJOR.MINOR `vX.Y` version.
 
   See also
   [release versioning](/contributors/design-proposals/release/versioning.md).
 
-- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
+- _release branch_: Git branch `release-X.Y` created for the `vX.Y` milestone.
 
   Created at the time of the `vX.Y-rc.0` release and maintained after the
   release for approximately 12 months with `vX.Y.Z` patch releases.
@@ -160,7 +161,7 @@ conjunction with the Release Team's [Enhancements Lead](https://git.k8s.io/sig-r
 
 After Enhancements Freeze, tracking milestones on PRs and issues is important.
 Items within the milestone are used as a punchdown list to complete the
-release. *On issues*, milestones must be applied correctly, via triage by the
+release. _On issues_, milestones must be applied correctly, via triage by the
 SIG, so that [Release Team][release-team] can track bugs and enhancements (any
 enhancement-related issue needs a milestone).
 
@@ -354,7 +355,7 @@ issue kind labels must be set:
 - `kind/feature`: New functionality.
 - `kind/flake`: CI test case is showing intermittent failures.
 
-[cherry-picks]: /contributors/devel/sig-release/cherry-picks.md
+[cherry-picks]: /community/blob/master/contributors/devel/sig-release/cherry-picks.md
 [code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze
 [enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze
 [exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions

content/es/docs/tutorials/_index.md

@@ -31,6 +31,8 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a
 
 ## Configuración
 
+* [Ejemplo: Configurando un Microservicio en Java](/docs/tutorials/configuration/configure-java-microservice/)
+
 * [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
 
 ## Aplicaciones Stateless

content/fr/docs/reference/glossary/container-runtime.md

@@ -2,7 +2,7 @@
 title: Container Runtime
 id: container-runtime
 date: 2019-06-05
-full_link: /docs/reference/generated/container-runtime
+full_link: /docs/setup/production-environment/container-runtimes
 short_description: >
  L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs.
 

content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -225,7 +225,7 @@ Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis s
 
 Parfois, les applications sont temporairement incapables de servir le trafic.
 Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage.
-Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
+Dans ces cas, vous ne voulez pas tuer l'application, mais vous ne voulez pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes.
 
 {{< note >}}
 Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie.

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

@@ -290,7 +290,7 @@ dan [panduan penggunaan metrik eksternal](/docs/tasks/run-application/horizontal
 
 ## Dukungan untuk Perilaku *Scaling* yang dapat Dikonfigurasi
 
-Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md), API `v2beta2` mengizinkan perilaku *scaling* dapat
+Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md), API `v2beta2` mengizinkan perilaku *scaling* dapat
 dikonfigurasi melalui *field* `behavior` pada HorizontalPodAutoscaler. Perilaku *scaling up* dan *scaling down*
 ditentukan terpisah pada *field* `slaceUp` dan *field* `scaleDown`, dibawah dari *field* `behavior`.
 Sebuah stabilisator dapat ditentukan untuk kedua arah *scale* untuk mencegah perubahan replika yang terlalu

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

@@ -20,7 +20,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ
 
 ## 設計
 
-![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg)
 
 クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。
 

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

@@ -50,7 +50,11 @@ Jobとは対照的に、クラスターの外部に変更を加える必要が
 
 外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。
 
-(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。)
+(クラスター内のノードを水平にスケールさせる[コントローラー](https://github.com/kubernetes/autoscaler/)が実際に存在します。)
+
+ここで重要な点は、コントローラーが目的の状態を実現するために変更を加えてから、現在の状態をクラスターのAPIサーバーに報告することです。他の制御ループは、その報告されたデータを監視し、独自のアクションを実行できます。
+
+サーモスタットの例では、部屋が非常に寒い場合、別のコントローラーが霜防止ヒーターをオンにすることもあります。Kubernetesクラスターを使用すると、コントロールプレーンは、[Kubernetesを拡張して](/ja/docs/concepts/extend-kubernetes/)実装することにより、IPアドレス管理ツールやストレージサービス、クラウドプロバイダーAPI、およびその他のサービスと間接的に連携します。
 
 ## 目的の状態 vs 現在の状態 {#desired-vs-current}
 
@@ -86,4 +90,3 @@ 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

@@ -275,4 +275,3 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント
 * [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/addons.md

@@ -0,0 +1,53 @@
+---
+title: アドオンのインストール
+content_type: concept
+---
+
+<!-- overview -->
+
+{{% thirdparty-content %}}
+
+アドオンはKubernetesの機能を拡張するものです。
+
+このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。
+
+<!-- body -->
+
+## ネットワークとネットワークポリシー
+
+* [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。
+* [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。
+* [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションをサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。
+* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。
+* [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。
+* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。
+* [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。
+* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。
+* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。
+* [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。
+* [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。
+* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。
+* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。
+* [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。
+
+## サービスディスカバリ
+
+* [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。
+
+## 可視化と制御
+
+* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。
+* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。
+
+## インフラストラクチャ
+
+* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。
+
+## レガシーなアドオン
+
+いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。
+
+よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。

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

@@ -1,327 +0,0 @@
----
-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/cluster-administration-overview.md

@@ -29,8 +29,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 ## クラスターの管理
 
-* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。
-
 * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。
 
 * 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
@@ -41,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る
 
 * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。
 
-* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。
+* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。
 
 * [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。
 

content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -0,0 +1,67 @@
+---
+title: コンテナイメージのガベージコレクション
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+
+ガベージコレクションは、未使用の[イメージ](/ja/docs/concepts/containers/#container-images)と未使用の[コンテナ](/ja/docs/concepts/containers/)をクリーンアップするkubeletの便利な機能です。kubeletコンテナのガベージコレクションを1分ごとに行い、イメージのガベージコレクションは5分ごとに行います。
+
+存在することが期待されているコンテナを削除してkubeletの動作を壊す可能性があるため、外部のガベージコレクションのツールは推奨されません。
+
+<!-- body -->
+
+## イメージのガベージコレクション
+
+Kubernetesでは、すべてのイメージのライフサイクルの管理はcadvisorと協調してimageManager経由で行います。
+
+イメージのガベージコレクションのポリシーについて考えるときは、`HighThresholdPercent`および`LowThresholdPercent`という2つの要因について考慮する必要があります。ディスク使用量がhigh thresholdを超えると、ガベージコレクションがトリガされます。ガベージコレクションは、low
+thresholdが満たされるまで、最後に使われてから最も時間が経った(least recently used)イメージを削除します。
+
+## コンテナのガベージコレクション
+
+コンテナのガベージコレクションのポリシーは、3つのユーザー定義の変数を考慮に入れます。`MinAge`は、ガベージコレクションできるコンテナの最小の年齢です。`MaxPerPodContainer`は、すべての単一のPod(UID、コンテナ名)が保持することを許されているdead状態のコンテナの最大値です。`MaxContainers`はdead状態のコンテナの合計の最大値です。これらの変数は、`MinAge`は0に、`MaxPerPodContainer`と`MaxContainers`は0未満にそれぞれ設定することで個別に無効にできます。
+
+kubeletは、未指定のコンテナ、削除されたコンテナ、前述のフラグにより設定された境界の外にあるコンテナに対して動作します。一般に、最も古いコンテナが最初に削除されます。`MaxPerPodContainer`と`MaxContainer`は、Podごとの保持するコンテナの最大値(`MaxPerPodContainer`)がグローバルのdead状態のコンテナの許容範囲(`MaxContainers`)外である場合には、互いに競合する可能性があります。このような状況では、`MaxPerPodContainer`が調整されます。最悪のケースのシナリオでは、`MaxPerPodContainer`が1にダウングレードされ、最も古いコンテナが強制退去されます。さらに、`MinAge`より古くなると、削除済みのPodが所有するコンテナが削除されます。
+
+kubeletによって管理されないコンテナは、コンテナのガベージコレクションの対象にはなりません。
+
+## ユーザー設定
+
+イメージのガベージコレクションを調整するために、以下のkubeletのフラグを使用して次のようなしきい値を調整できます。
+
+1. `image-gc-high-threshold`: イメージのガベージコレクションをトリガするディスク使用量の割合(%)。デフォルトは85%。
+2. `image-gc-low-threshold`: イメージのガベージコレクションが解放を試みるディスク使用量の割合(%)。デフォルトは80%。
+
+ガベージコレクションのポリシーは、以下のkubeletのフラグを使用してカスタマイズできます。
+
+1. `minimum-container-ttl-duration`: 完了したコンテナがガベージコレクションされる前に経過するべき最小期間。デフォルトは0分です。つまり、すべての完了したコンテナはガベージコレクションされます。
+2. `maximum-dead-containers-per-container`: コンテナごとに保持される古いインスタンスの最大値です。デフォルトは1です。
+3. `maximum-dead-containers`: グローバルに保持するべき古いコンテナのインスタンスの最大値です。デフォルトは-1です。つまり、グローバルなリミットは存在しません。
+
+コンテナは役に立たなくなる前にガベージコレクションされる可能性があります。こうしたコンテナには、トラブルシューティングに役立つログや他のデータが含まれるかもしれません。そのため、期待されるコンテナごとに最低でも1つのdead状態のコンテナが許容されるようにするために、`maximum-dead-containers-per-container`には十分大きな値を設定することが強く推奨されます。同様の理由で、`maximum-dead-containers`にも、より大きな値を設定することが推奨されます。詳しくは、[こちらのissue](https://github.com/kubernetes/kubernetes/issues/13287)を読んでください。
+
+## 廃止
+
+このドキュメントにあるkubeletの一部のガベージコレクションの機能は、将来kubelet evictionで置換される予定です。
+
+これには以下のものが含まれます。
+
+| 既存のフラグ | 新しいフラグ | 理由 |
+| ------------- | -------- | --------- |
+| `--image-gc-high-threshold` | `--eviction-hard`または`--eviction-soft` | 既存のevictionのシグナルがイメージのガベージコレクションをトリガする可能性がある |
+| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaimが同等の動作を実現する |
+| `--maximum-dead-containers` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
+| `--maximum-dead-containers-per-container` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
+| `--minimum-container-ttl-duration` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
+| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | evictionはディスクのしきい値を他のリソースに一般化している |
+| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | evictionはディスクのpressure transitionを他のリソースに一般化している |
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+詳細については、[リソース不足のハンドリング方法を設定する](/docs/tasks/administer-cluster/out-of-resource/)を参照してください。
+

content/ja/docs/concepts/cluster-administration/networking.md

@@ -39,7 +39,7 @@ Kubernetesは、ネットワークの実装に次の基本的な要件を課し
 
 このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。
 
-KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
+KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスとMACアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。
 
 この実装方法は実際に使われているコンテナランタイムの詳細部分です。
 
@@ -51,6 +51,8 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の
 
 この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。
 
+{{% thirdparty-content %}}
+
 ### ACI
 
 [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers.
@@ -99,6 +101,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c
 
 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/).
 
+### Calico
+
+[Calico](https://docs.projectcalico.org/)は、コンテナ、仮想マシン、ホストベースのワークロードのためのオープンソースのネットワーク及びネットワークセキュリティのソリューションです。Calicoは、純粋なLinuxのeBPFデータプレーンや、Linuxの標準的なネットワークデータプレーン、WindowsのHNSデータプレーンを含む、複数のデータプレーンをサポートしています。Calicoは完全なネットワークスタックを提供していますが、[クラウドプロバイダーのCNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)と組み合わせてネットワークポリシーを提供することもできます。
+
 ### Cilium
 
 [Cilium](https://github.com/cilium/cilium) is open source software for
@@ -129,6 +135,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100
 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
 network complexity required to deploy Kubernetes at scale within AWS.
 
+### Coil
+
+[Coil](https://github.com/cybozu-go/coil)は、容易に連携できるよう設計されていて、フレキシブルなEgressネットワークを提供することができるCNIプラグインです。
+Coilはベアメタルと比較して低いオーバーヘッドで操作することができ、また外部のネットワークへの任意のEgress NATゲートウェイを定義することができます。
+
 ### 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](https://contiv.io) is all open sourced.
@@ -266,14 +277,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
 topologies.  The project has a specific Kubernetes plugin and documentation
 at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 
-### Project Calico
-
-[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.
-
-Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking.
-
 ### Romana
 
 [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.
@@ -287,9 +290,7 @@ or stand-alone.  In either version, it doesn't require any configuration or extr
 to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
 
 
-
 ## {{% heading "whatsnext" %}}
 
 
 ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。
-

content/ja/docs/concepts/cluster-administration/system-logs.md

@@ -0,0 +1,126 @@
+---
+title: システムログ
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。
+
+<!-- body -->
+
+## klog
+
+klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。
+
+klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。
+
+klogネイティブ形式の例:
+
+```
+I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
+```
+
+### 構造化ログ
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+{{< warning >}}
+構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。
+
+ログの形式と値のシリアライズは変更される可能性があります。
+{{< /warning>}}
+
+構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。
+
+構造化ログの形式:
+
+```ini
+<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
+```
+
+例:
+
+```ini
+I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
+```
+
+
+### JSONログ形式
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+{{<warning >}}
+JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。
+
+すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。
+
+フィールド名とJSONのシリアライズは変更される可能性があります。
+{{< /warning >}}
+
+`--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。
+
+```json
+{
+   "ts": 1580306777.04728,
+   "v": 4,
+   "msg": "Pod status updated",
+   "pod":{
+      "name": "nginx-1",
+      "namespace": "default"
+   },
+   "status": "ready"
+}
+```
+
+特別な意味を持つキー:
+* `ts` - Unix時間のタイムスタンプ(必須、float)
+* `v` - verbosity (必須、int、デフォルトは0)
+* `err` - エラー文字列 (オプション、string)
+* `msg` - メッセージ (必須、string)
+
+現在サポートされているJSONフォーマットの一覧:
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+### ログのサニタイズ
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+{{<warning >}}
+ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。
+{{< /warning >}}
+
+`--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。
+
+現在ログのサニタイズをサポートしているコンポーネント一覧:
+* kube-controller-manager
+* kube-apiserver
+* kube-scheduler
+* kubelet
+
+{{< note >}}
+ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。
+{{< /note >}}
+
+### ログのverbosityレベル
+
+`-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。
+
+### ログの場所
+
+システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。
+
+* Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。
+* kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。
+
+systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。
+
+## {{% heading "whatsnext" %}}
+
+* [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。
+* [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。
+* [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。

content/ja/docs/concepts/configuration/configmap.md

@@ -22,12 +22,18 @@ ConfigMapは機密性や暗号化を提供しません。保存したいデー
 
 こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。
 
+ConfigMapは、大量のデータを保持するようには設計されていません。ConfigMapに保存されるデータは1MiBを超えることはできません。この制限を超える設定を保存する必要がある場合は、ボリュームのマウントを検討するか、別のデータベースまたはファイルサービスを使用することを検討してください。
+
 ## ConfigMapオブジェクト
 
-ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。
+ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapには`data`および`binaryData`フィールドがあります。これらのフィールドは、キーとバリューのペアを値として受け入れます。`data`フィールドと`binaryData`フィールドはどちらもオプションです。`data`フィールドはUTF-8バイトシーケンスを含むように設計されていますが、`binaryData`フィールドはバイナリデータを含むように設計されています。
 
 ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
 
+`data`または`binaryData`フィールドの各キーは、英数字、`-`、`_`、または`.`で構成されている必要があります。`data`に格納されているキーは、`binaryData`フィールドのキーと重複することはできません。
+
+v1.19以降、ConfigMapの定義に`immutable`フィールドを追加して、[イミュータブルなConfigMap](#configmap-immutable)を作成できます。
+
 ## ConfigMapとPod
 
 ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。
@@ -43,7 +49,7 @@ data:
   # プロパティーに似たキー。各キーは単純な値にマッピングされている
   player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
-  #
+
   # ファイルに似たキー
   game.properties: |
     enemy.types=aliens,monsters
@@ -56,7 +62,7 @@ data:
 
 ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。
 
-1. コマンドライン引数をコンテナのエントリーポイントに渡す
+1. コンテナ内のコマンドと引数
 1. 環境変数をコンテナに渡す
 1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る
 1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する
@@ -75,7 +81,8 @@ metadata:
 spec:
   containers:
     - name: demo
-      image: game.example/demo-game
+      image: alpine
+      command: ["sleep", "3600"]
       env:
         # 環境変数を定義します。
         - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い
@@ -117,11 +124,9 @@ ConfigMapは1行のプロパティの値と複数行のファイルに似た形
 
 ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。
 
-{{< note >}}
 ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。
 
 たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。
-{{< /note >}}
 
 ### ConfigMapをPodからファイルとして使う
 
@@ -161,14 +166,17 @@ Pod内に複数のコンテナが存在する場合、各コンテナにそれ
 
 ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+環境変数として使用されるConfigMapは自動的に更新されないため、ポッドを再起動する必要があります。
+## イミュータブルなConfigMap {#configmap-immutable}
 
-Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+Kubernetesのベータ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。
 
 - アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる
 - ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する
 
-この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。
+この機能は、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって管理されます。`immutable`フィールドを`true`に設定することで、イミュータブルなConfigMapを作成できます。次に例を示します。
 
 ```yaml
 apiVersion: v1
@@ -180,9 +188,7 @@ data:
 immutable: true
 ```
 
-{{< note >}}
+一度ConfigMapがイミュータブルに設定されると、この変更を元に戻したり、`data`または`binaryData`フィールドのコンテンツを変更することは*できません*。ConfigMapの削除と再作成のみ可能です。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
-一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。
-{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 

content/ja/docs/concepts/configuration/manage-resources-containers.md

@@ -29,6 +29,10 @@ Podが動作しているNodeに利用可能なリソースが十分にある場
 制限は、違反が検出されるとシステムが介入するように事後的に、またはコンテナーが制限を超えないようにシステムが防ぐように強制的に、実装できます。
 異なるランタイムは、同じ制限を実装するために異なる方法をとることができます。
 
+{{< note >}}
+コンテナが自身のメモリー制限を指定しているが、メモリー要求を指定していない場合、Kubernetesは制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナが自身のCPU制限を指定しているが、CPU要求を指定していない場合、Kubernetesは制限に一致するCPU要求を自動的に割り当てます。
+{{< /note >}}
+
 ## リソースタイプ
 
 *CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
@@ -106,7 +110,6 @@ spec:
   containers:
   - name: app
     image: images.my-company.example/app:v4
-    env:
     resources:
       requests:
         memory: "64Mi"
@@ -234,7 +237,7 @@ kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラ
 
 ### ローカルのエフェメラルストレージの要求と制限設定
 
-ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。
+ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。
 Podの各コンテナは、次の1つ以上を指定できます。
 * `spec.containers[].resources.limits.ephemeral-storage`
 * `spec.containers[].resources.requests.ephemeral-storage`

content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -0,0 +1,114 @@
+---
+title: kubeconfigファイルを使用してクラスターアクセスを組織する
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+kubeconfigを使用すると、クラスターに、ユーザー、名前空間、認証の仕組みに関する情報を組織できます。`kubectl`コマンドラインツールはkubeconfigファイルを使用してクラスターを選択するために必要な情報を見つけ、クラスターのAPIサーバーと通信します。
+
+{{< note >}}
+クラスターへのアクセスを設定するために使われるファイルは*kubeconfigファイル*と呼ばれます。これは設定ファイルを指すために使われる一般的な方法です。`kubeconfig`という名前を持つファイルが存在するという意味ではありません。
+{{< /note >}}
+
+デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。
+
+kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
+
+<!-- body -->
+
+## 複数のクラスター、ユーザ、認証の仕組みのサポート
+
+複数のクラスターを持っていて、ユーザーやコンポーネントがさまざまな方法で認証を行う次のような状況を考えてみます。
+
+- 実行中のkubeletが証明書を使用して認証を行う可能性がある。
+- ユーザーがトークンを使用して認証を行う可能性がある。
+- 管理者が個別のユーザに提供する複数の証明書を持っている可能性がある。
+
+kubeconfigファイルを使用すると、クラスター、ユーザー、名前空間を組織化することができます。また、contextを定義することで、複数のクラスターや名前空間を素早く簡単に切り替えられます。
+
+## Context
+
+kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。
+
+current contextを選択するには、以下のコマンドを使用します。
+
+```
+kubectl config use-context
+```
+
+## KUBECONFIG環境変数
+
+`KUBECONFIG`環境変数には、kubeconfigファイルのリストを指定できます。LinuxとMacでは、リストはコロン区切りです。Windowsでは、セミコロン区切りです。`KUBECONFIG`環境変数は必須ではありません。`KUBECONFIG`環境変数が存在しない場合は、`kubectl`はデフォルトのkubeconfigファイルである`$HOME/.kube/config`を使用します。
+
+`KUBECONFIG`環境変数が存在する場合は、`kubectl`は`KUBECONFIG`環境変数にリストされているファイルをマージした結果を有効な設定として使用します。
+
+## kubeconfigファイルのマージ
+
+設定ファイルを確認するには、以下のコマンドを実行します。
+
+```shell
+kubectl config view
+```
+
+上で説明したように、出力は1つのkubeconfigファイルから作られる場合も、複数のkubeconfigファイルをマージした結果となる場合もあります。
+
+`kubectl`がkubeconfigファイルをマージするときに使用するルールを以下に示します。
+
+1. もし`--kubeconfig`フラグが設定されていた場合、指定したファイルだけが使用されます。マージは行いません。このフラグに指定できるのは1つのファイルだけです。
+
+   そうでない場合、`KUBECONFIG`環境変数が設定されていた場合には、それをマージするべきファイルのリストとして使用します。`KUBECONFIG`環境変数にリストされたファイルのマージは、次のようなルールに従って行われます。
+
+   * 空のファイルを無視する。
+   * デシリアライズできない内容のファイルに対してエラーを出す。
+   * 特定の値やmapのキーを設定する最初のファイルが勝つ。
+   * 値やmapのキーは決して変更しない。
+     例: 最初のファイルが指定した`current-context`を保持する。
+     例: 2つのファイルが`red-user`を指定した場合、1つ目のファイルの`red-user`だけを使用する。もし2つ目のファイルの`red-user`以下に競合しないエントリーがあったとしても、それらは破棄する。
+
+   `KUBECONFIG`環境変数を設定する例については、[KUBECONFIG環境変数を設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)を参照してください。
+
+   それ以外の場合は、デフォルトのkubeconfigファイル`$HOME/.kube/config`をマージせずに使用します。
+
+1. 以下のチェーンで最初に見つかったものをもとにして、使用するcontextを決定する。
+
+    1. `--context`コマンドラインフラグが存在すれば、それを使用する。
+    1. マージしたkubeconrfigファイルから`current-context`を使用する。
+
+   この時点では、空のcontextも許容されます。
+
+1. クラスターとユーザーを決定する。この時点では、contextである場合もそうでない場合もあります。以下のチェーンで最初に見つかったものをもとにして、クラスターとユーザーを決定します。この手順はユーザーとクラスターについてそれぞれ1回ずつ、合わせて2回実行されます。
+
+   1. もし存在すれば、コマンドラインフラグ`--user`または`--cluster`を使用する。
+   1. もしcontextが空でなければ、contextからユーザーまたはクラスターを取得する。
+
+   この時点では、ユーザーとクラスターは空である可能性があります。
+
+1. 使用する実際のクラスター情報を決定する。この時点では、クラスター情報は存在しない可能性があります。以下のチェーンで最初に見つかったものをもとにして、クラスター情報の各パーツをそれぞれを構築します。
+
+   1. もし存在すれば、`--server`、`--certificate-authority`、`--insecure-skip-tls-verify`コマンドラインフラグを使用する。
+   1. もしマージしたkubeconfigファイルにクラスター情報の属性が存在すれば、それを使用する。
+   1. もしサーバーの場所が存在しなければ、マージは失敗する。
+
+1. 使用する実際のユーザー情報を決定する。クラスター情報の場合と同じルールを使用して、ユーザー情報を構築します。ただし、ユーザーごとに許可される認証方法は1つだけです。
+
+   1. もし存在すれば、`--client-certificate`、`--client-key`、`--username`、`--password`、`--token`コマンドラインフラグを使用する。
+   1. マージしたkubeconfigファイルの`user`フィールドを使用する。
+   1. もし2つの競合する方法が存在する場合、マージは失敗する。
+
+1. もし何らかの情報がまだ不足していれば、デフォルトの値を使用し、認証情報については場合によってはプロンプトを表示する。
+
+## ファイルリファレンス
+
+kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。
+
+## {{% heading "whatsnext" %}}
+
+
+* [複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
+
+
+
+

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

@@ -58,11 +58,11 @@ weight: 10
 
 ## ラベルの使用
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
 
 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
 
-オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
+オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
 
 - デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。
 

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

@@ -1,5 +1,5 @@
 ---
-title: Secrets
+title: Secret
 content_type: concept
 feature:
   title: Secretと構成管理
@@ -11,18 +11,18 @@ weight: 30
 <!-- overview -->
 
 KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。
-Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
+Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。
+詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
 
+Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
+他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
+ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
 
 
 <!-- body -->
 
 ## Secretの概要
 
-Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
-他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
-ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
-
 Secretを使うには、PodはSecretを参照することが必要です。
 PodがSecretを使う方法は3種類あります。
 
@@ -30,392 +30,292 @@ PodがSecretを使う方法は3種類あります。
 - [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する
 - Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する
 
-### 内蔵のSecret
 
-#### 自動的にサービスアカウントがAPIの認証情報のSecretを生成し、アタッチする
-
-KubernetesはAPIにアクセスするための認証情報を含むSecretを自動的に生成し、この種のSecretを使うように自動的にPodを改変します。
-
-必要であれば、APIの認証情報が自動生成され利用される機能は無効化したり、上書きしたりすることができます。しかし、安全にAPIサーバーでアクセスすることのみが必要なのであれば、これは推奨されるワークフローです。
-
-サービスアカウントがどのように機能するのかについては、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)
-のドキュメントを参照してください。
-
-### Secretを作成する
-
-#### `kubectl`を利用してSecretを作成する
-
-SecretにはPodがデータベースにアクセスするために必要な認証情報を含むことができます。
-例えば、ユーザー名とパスワードからなる接続文字列です。
-ローカルマシンのファイル`./username.txt`にユーザー名を、ファイル`./password.txt`にパスワードを保存することができます。
-
-```shell
-# この後の例で使用するファイルを作成します
-echo -n 'admin' > ./username.txt
-echo -n '1f2d1e2e67df' > ./password.txt
-```
-
-`kubectl create secret`コマンドはそれらのファイルをSecretに格納して、APIサーバー上でオブジェクトを作成します。
 Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
+シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。
+`data`フィールドのすべてのキーの値は、base64でエンコードされた文字列である必要があります。
+base64文字列への変換が望ましくない場合は、代わりに`stringData`フィールドを指定することを選択できます。これは任意の文字列を値として受け入れます。
+
+
+`data`と`stringData`のキーは、英数字、`-`、`_`、または`.`で構成されている必要があります。
+`stringData`フィールドのすべてのキーと値のペアは、内部で`data`フィールドにマージされます。
+キーが`data`フィールドと`stringData`フィールドの両方に表示される場合、`stringData`フィールドで指定された値が優先されます。
+
+## Secretの種類 {#secret-types}
+
+Secretを作成するときは、[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)の`type`フィールド、または特定の同等の`kubectl`コマンドラインフラグ（使用可能な場合）を使用して、その型を指定できます。
+Secret型は、Secret dataのプログラムによる処理を容易にするために使用されます。
+
+Kubernetesは、いくつかの一般的な使用シナリオに対応するいくつかの組み込み型を提供します。
+これらの型は、実行される検証とKubernetesが課す制約の点で異なります。
+
+| Builtin Type | Usage |
+|--------------|-------|
+| `Opaque`     |  arbitrary user-defined data |
+| `kubernetes.io/service-account-token` | service account token |
+| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file |
+| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file |
+| `kubernetes.io/basic-auth` | credentials for basic authentication |
+| `kubernetes.io/ssh-auth` | credentials for SSH authentication |
+| `kubernetes.io/tls` | data for a TLS client or server |
+| `bootstrap.kubernetes.io/token` | bootstrap token data |
+
+Secretオブジェクトの`type`値として空でない文字列を割り当てることにより、独自のSecret型を定義して使用できます。空の文字列は`Opaque`型として扱われます。Kubernetesは型名に制約を課しません。ただし、組み込み型の1つを使用している場合は、その型に定義されているすべての要件を満たす必要があります。
+
+### Opaque secrets
+
+`Opaque`は、Secret構成ファイルから省略された場合のデフォルトのSecret型です。
+`kubectl`を使用してSecretを作成する場合、`generic`サブコマンドを使用して`Opaque`Secret型を示します。 たとえば、次のコマンドは、`Opaque`型の空のSecretを作成します。
 
 ```shell
-kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
+kubectl create secret generic empty-secret
-```
+kubectl get secret empty-secret
-
-次のように出力されます:
-
-```
-secret "db-user-pass" created
-```
-
-デフォルトのキー名はファイル名です。`[--from-file=[key=]source]`を使って任意でキーを指定することができます。
-
-```shell
-kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
-```
-
-{{< note >}}
-`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。
-ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。
-例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。
-
-```shell
-kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
-```
-
-`--from-file`を使ってファイルからパスワードを読み込む場合、ファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。
-{{< /note >}}
-
-Secretが作成されたことを確認できます。
-
-```shell
-kubectl get secrets
 ```
 
 出力は次のようになります。
 
 ```
-NAME                  TYPE                                  DATA      AGE
+NAME           TYPE     DATA   AGE
-db-user-pass          Opaque                                2         51s
+empty-secret   Opaque   0      2m6s
 ```
 
-Secretの説明を参照することができます。
+`DATA`列には、Secretに保存されているデータ項目の数が表示されます。
+この場合、`0`は空のSecretを作成したことを意味します。
 
-```shell
+###  Service account token Secrets
-kubectl describe secrets/db-user-pass
-```
 
-出力は次のようになります。
+`kubernetes.io/service-account-token`型のSecretは、サービスアカウントを識別するトークンを格納するために使用されます。 このSecret型を使用する場合は、`kubernetes.io/service-account.name`アノテーションが既存のサービスアカウント名に設定されていることを確認する必要があります。Kubernetesコントローラーは、`kubernetes.io/service-account.uid`アノテーションや実際のトークンコンテンツに設定された`data`フィールドの`token`キーなど、他のいくつかのフィールドに入力します。
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-{{< note >}}
-`kubectl get`や`kubectl describe`コマンドはデフォルトではSecretの内容の表示を避けます。
-これはSecretを誤って盗み見られたり、ターミナルのログへ記録されてしまったりすることがないよう保護するためです。
-{{< /note >}}
-
-Secretの内容を参照する方法は[Secretのデコード](#decoding-a-secret)を参照してください。
-
-#### 手動でSecretを作成する
-
-SecretをJSONまたはYAMLフォーマットのファイルで作成し、その後オブジェクトを作成することができます。
-Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
-[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)は、`data`と`stringData`の2つの連想配列を持ちます。
-`data`フィールドは任意のデータの保存に使われ、Base64でエンコードされています。
-`stringData`は利便性のために存在するもので、機密データをエンコードされない文字列で扱えます。
-
-例えば、`data`フィールドを使って1つのSecretに2つの文字列を保存するには、次のように文字列をBase64エンコードします。
-
-```shell
-echo -n 'admin' | base64
-```
-
-出力は次のようになります。
-
-```
-YWRtaW4=
-```
-
-```shell
-echo -n '1f2d1e2e67df' | base64
-```
-
-出力は次のようになります。
-
-```
-MWYyZDFlMmU2N2Rm
-```
-
-このようなSecretを書きます。
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
+  name: secret-sa-sample
-type: Opaque
+  annotations:
+    kubernetes.io/service-account.name: "sa-name"
+type: kubernetes.io/service-account-token
 data:
-  username: YWRtaW4=
+  # You can include additional key value pairs as you do with Opaque Secrets
-  password: MWYyZDFlMmU2N2Rm
+  extra: YmFyCg==
 ```
 
-これでSecretを[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドで作成できるようになりました。
+`Pod`を作成すると、Kubernetesはservice account Secretを自動的に作成し、このSecretを使用するようにPodを自動的に変更します。service account token Secretには、APIにアクセスするための資格情報が含まれています。
 
-```shell
+API証明の自動作成と使用は、必要に応じて無効にするか、上書きすることができます。 ただし、API Serverに安全にアクセスするだけの場合は、これが推奨されるワークフローです。
-kubectl apply -f ./secret.yaml
-```
 
-出力は次のようになります。
+ServiceAccountの動作の詳細については、[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)のドキュメントを参照してください。
+PodからServiceAccountを参照する方法については、[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)の`automountServiceAccountToken`フィールドと`serviceAccountName`フィールドを確認することもできます。
 
-```
+### Docker config Secrets
-secret "mysecret" created
-```
 
-状況によっては、代わりに`stringData`フィールドを使いたいときもあるでしょう。
+次の`type`値のいずれかを使用して、イメージのDockerレジストリにアクセスするための資格情報を格納するSecretを作成できます。
-このフィールドを使えばBase64でエンコードされていない文字列を直接Secretに書くことができて、その文字列はSecretが作られたり更新されたりするときにエンコードされます。
 
-実用的な例として、設定ファイルの格納にSecretを使うアプリケーションをデプロイすることを考えます。
+- `kubernetes.io/dockercfg`
-デプロイプロセスの途中で、この設定ファイルの一部のデータを投入したいとしましょう。
+- `kubernetes.io/dockerconfigjson`
 
-例えば、アプリケーションは次のような設定ファイルを使用するとします。
+
+`kubernetes.io/dockercfg`型は、Dockerコマンドラインを構成するためのレガシー形式であるシリアル化された`~/.dockercfg`を保存するために予約されています。
+このSecret型を使用する場合は、Secretの`data`フィールドに`.dockercfg`キーが含まれていることを確認する必要があります。このキーの値は、base64形式でエンコードされた`~/.dockercfg`ファイルの内容です。
+
+`kubernetes.io/dockerconfigjson`型は、`~/.dockercfg`の新しいフォーマットである`~/.docker/config.json`ファイルと同じフォーマットルールに従うシリアル化されたJSONを保存するために設計されています。
+このSecret型を使用する場合、Secretオブジェクトの`data`フィールドには`.dockerconfigjson`キーが含まれている必要があります。このキーでは、`~/.docker/config.json`ファイルのコンテンツがbase64でエンコードされた文字列として提供されます。
+
+以下は、`kubernetes.io/dockercfg`型のSecretの例です。
 
 ```yaml
-apiUrl: "https://my.api.com/api/v1"
+apiVersion: v1
-username: "user"
+kind: Secret
-password: "password"
+  name: secret-dockercfg
+type: kubernetes.io/dockercfg
+ data:
+  .dockercfg: |
+    "<base64 encoded ~/.dockercfg file>"
 ```
 
-次のような定義を使用して、この設定ファイルをSecretに保存することができます。
+{{< note >}}
+base64エンコーディングを実行したくない場合は、代わりに`stringData`フィールドを使用することを選択できます。
+{{< /note >}}
+
+マニフェストを使用してこれらの型のSecretを作成すると、APIserverは期待されるキーが`data`フィールドに存在するかどうかを確認し、提供された値を有効なJSONとして解析できるかどうかを確認します。APIサーバーは、JSONが実際にDocker configファイルであるかどうかを検証しません。
+
+
+Docker configファイルがない場合、または`kubectl`を使用してDockerレジストリSecretを作成する場合は、次の操作を実行できます。
+
+```shell
+kubectl create secret docker-registry secret-tiger-docker \
+  --docker-username=tiger \
+  --docker-password=pass113 \
+  --docker-email=tiger@acme.com
+```
+
+このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。
+`data`フィールドから`.dockerconfigjson`コンテンツをダンプすると、その場で作成された有効なDocker configである次のJSONコンテンツを取得します。
+
+```json
+{
+  "auths": {
+    "https://index.docker.io/v1/": {
+      "username": "tiger",
+      "password": "pass113",
+      "email": "tiger@acme.com",
+      "auth": "dGlnZXI6cGFzczExMw=="
+    }
+  }
+}
+```
+
+### Basic authentication Secret
+
+`kubernetes.io/basic-auth`型は、Basic認証に必要な認証を保存するために提供されています。このSecret型を使用する場合、Secretの`data`フィールドには次の2つのキーが含まれている必要があります。
+
+- `username`: 認証のためのユーザー名
+- `password`: 認証のためのパスワードかトークン
+
+上記の2つのキーの両方の値は、base64でエンコードされた文字列です。もちろん、Secretの作成に`stringData`を使用してクリアテキストコンテンツを提供することもできます。
+
+次のYAMLは、Basic authentication Secretの設定例です。
+
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
+  name: secret-basic-auth
-type: Opaque
+type: kubernetes.io/basic-auth
 stringData:
-  config.yaml: |-
+  username: admin
-    apiUrl: "https://my.api.com/api/v1"
+  password: t0p-Secret
-    username: {{username}}
-    password: {{password}}
 ```
 
-デプロイツールは`kubectl apply`を実行する前に`{{username}}`と`{{password}}`のテンプレート変数を置換することができます。
 
-`stringData`フィールドは利便性のための書き込み専用フィールドです。
+Basic認証Secret型は、ユーザーの便宜のためにのみ提供されています。Basic認証に使用される資格情報の`Opaque`を作成できます。
-Secretを取得するときに出力されることは決してありません。
+ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
-例えば、次のコマンドを実行すると、
+
+
+### SSH authentication secrets
+
+組み込みのタイプ`kubernetes.io/ssh-auth`は、SSH認証で使用されるデータを保存するために提供されています。このSecret型を使用する場合、使用するSSH認証として`data`（または`stringData`）フィールドに`ssh-privatekey`キーと値のペアを指定する必要があります。 
+
+次のYAMLはSSH authentication Secretの設定例です：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: secret-ssh-auth
+type: kubernetes.io/ssh-auth
+data:
+  # the data is abbreviated in this example
+  ssh-privatekey: |
+     MIIEpQIBAAKCAQEAulqb/Y ...
+```
+
+SSH authentication Secret型は、ユーザーの便宜のためにのみ提供されています。
+SSH認証に使用される資格情報の`Opaque`を作成できます。
+ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。
+
+### TLS secrets
+
+Kubernetesは、TLSに通常使用される証明書とそれに関連付けられたキーを保存するための組み込みのSecret型`kubernetes.io/tls`を提供します。このデータは、主にIngressリソースのTLS terminationで使用されますが、他のリソースで使用されることも、ワークロードによって直接使用されることもあります。
+このSecret型を使用する場合、APIサーバーは各キーの値を実際には検証しませんが、`tls.key`および`tls.crt`キーをSecret configurationの`data`（または`stringData`）フィールドに指定する必要があります。
+
+
+次のYAMLはTLS Secretの設定例です：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: secret-tls
+type: kubernetes.io/tls
+data:
+  # the data is abbreviated in this example
+  tls.crt: |
+    MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
+  tls.key: |
+    MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
+```
+
+TLS Secret型は、ユーザーの便宜のために提供されています。 TLSサーバーやクライアントに使用される資格情報の`Opaque`を作成できます。ただし、組み込みのSecret型を使用すると、プロジェクトでSecret形式の一貫性を確保できます。APIserverは、必要なキーがSecret configurationで提供されているかどうかを確認します。
+
+`kubectl`を使用してTLS Secretを作成する場合、次の例に示すように`tls`サブコマンドを使用できます。
 
 ```shell
-kubectl get secret mysecret -o yaml
+kubectl create secret tls my-tls-secret \
+  --cert=path/to/cert/file \
+  --key=path/to/key/file
 ```
 
-出力は次のようになります。
+
+公開鍵と秘密鍵のペアは、事前に存在している必要があります。`--cert`の公開鍵証明書は.PEMエンコード（Base64エンコードDER形式）であり、`--key`の指定された秘密鍵と一致する必要があります。
+秘密鍵は、一般にPEM秘密鍵形式と呼ばれる暗号化されていない形式である必要があります。どちらの場合も、PEMの最初と最後の行（たとえば、`-------- BEGIN CERTIFICATE -----`と`------- END CERTIFICATE ----`）は含まれて*いません*。
+
+### Bootstrap token Secrets
+
+Bootstrap token Secretは、Secretの`type`を`bootstrap.kubernetes.io/token`に明示的に指定することで作成できます。このタイプのSecretは、ノードのブートストラッププロセス中に使用されるトークン用に設計されています。よく知られているConfigMapに署名するために使用されるトークンを格納します。
+
+Bootstrap toke Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-<token-id>`の形式で名前が付けられます。ここで`<token-id>`はトークンIDの6文字の文字列です。
+
+Kubernetesマニフェストとして、Bootstrap token Secretは次のようになります。
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  creationTimestamp: 2018-11-15T20:40:59Z
+  name: bootstrap-token-5emitj
-  name: mysecret
+  namespace: kube-system
-  namespace: default
+type: bootstrap.kubernetes.io/token
-  resourceVersion: "7225"
-  uid: c280ad2e-e916-11e8-98f2-025000000001
-type: Opaque
 data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
+  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
+  token-id: NWVtaXRq
+  token-secret: a3E0Z2lodnN6emduMXAwcg==
+  usage-bootstrap-authentication: dHJ1ZQ==
+  usage-bootstrap-signing: dHJ1ZQ==
 ```
 
-`username`のようなフィールドを`data`と`stringData`の両方で指定すると、`stringData`の値が使用されます。
+
-例えば、次のSecret定義からは
+Bootstrap type Secretには、`data`で指定された次のキーがあります。
+
+- `token_id`：トークン識別子としてのランダムな6文字の文字列。必須。
+- `token-secret`：実際のtoken secretとしてのランダムな16文字の文字列。必須。
+- `description`：トークンの使用目的を説明する人間が読める文字列。オプション。
+- `expiration`：トークンの有効期限を指定するRFC3339を使用した絶対UTC時間。オプション。
+- `usage-bootstrap-<usage>`：Bootstrap tokenの追加の使用法を示すブールフラグ。
+- `auth-extra-groups`：`system：bootstrappers`グループに加えて認証されるグループ名のコンマ区切りのリスト。
+
+上記のYAMLは、値がすべてbase64でエンコードされた文字列であるため、混乱しているように見える場合があります。実際、次のYAMLを使用して同一のSecretを作成できます。
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
-  name: mysecret
+  # Note how the Secret is named
-type: Opaque
+  name: bootstrap-token-5emitj
-data:
+  # A bootstrap token Secret usually resides in the kube-system namespace
-  username: YWRtaW4=
+  namespace: kube-system
+type: bootstrap.kubernetes.io/token
 stringData:
-  username: administrator
+  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
+  expiration: "2020-09-13T04:39:10Z"
+  # This token ID is used in the name
+  token-id: "5emitj"
+  token-secret: "kq4gihvszzgn1p0r"
+  # This token can be used for authentication
+  usage-bootstrap-authentication: "true"
+  # and it can be used for signing
+  usage-bootstrap-signing: "true"
 ```
 
-次のようなSecretが生成されます。
+## Secretの作成
 
-```yaml
+Secretを作成するには、いくつかのオプションがあります。
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2018-11-15T20:46:46Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "7579"
-  uid: 91460ecb-e917-11e8-98f2-025000000001
-type: Opaque
-data:
-  username: YWRtaW5pc3RyYXRvcg==
-```
 
-`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`になります。
+- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 
-`data`や`stringData`のキーは英数字または'-'、'_'、'.'からなる必要があります。
+## Secretの編集
-
-{{< note >}}
-シリアライズされたJSONやYAMLの機密データはBase64エンコードされています。
-文字列の中の改行は不正で、含まれていてはなりません。
-Darwin/macOSの`base64`ユーティリティーを使うときは、長い行を分割する`-b`オプションを指定するのは避けるべきです。
-反対に、Linuxユーザーは`base64`コマンドに`-w 0`オプションを指定するか、`-w`オプションが使えない場合は`base64 | tr -d '\n'`のようにパイプ*すべき*です。
-{{< /note >}}
-
-#### ジェネレーターからSecretを作成する
-
-Kubernetes v1.14から、`kubectl`は[Kustomizeを使ったオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)に対応しています。
-KustomizeはSecretやConfigMapを生成するリソースジェネレーターを提供します。
-Kustomizeのジェネレーターはディレクトリの中の`kustomization.yaml`ファイルにて指定されるべきです。
-Secretが生成された後には、`kubectl apply`コマンドを使用してAPIサーバー上にSecretを作成することができます。
-
-#### ファイルからのSecretの生成
-
-./username.txtと./password.txtのファイルから生成するように`secretGenerator`を定義することで、Secretを生成することができます。
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  files:
-  - username.txt
-  - password.txt
-EOF
-```
-
-Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
-
-```shell
-kubectl apply -k .
-```
-
-出力は次のようになります。
-
-```
-secret/db-user-pass-96mffmfh4k created
-```
-
-Secretが生成されたことを確認できます。
-
-```shell
-kubectl get secrets
-```
-
-出力は次のようになります。
-
-```
-NAME                             TYPE                                  DATA      AGE
-db-user-pass-96mffmfh4k          Opaque                                2         51s
-```
-
-```shell
-kubectl describe secrets/db-user-pass-96mffmfh4k
-```
-
-出力は次のようになります。
-
-```
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-#### 文字列リテラルからのSecretの生成
-
-リテラル`username=admin`と`password=secret`から生成するように`secretGenerator`を定義して、Secretを生成することができます。
-
-```shell
-cat <<EOF >./kustomization.yaml
-secretGenerator:
-- name: db-user-pass
-  literals:
-  - username=admin
-  - password=secret
-EOF
-```
-
-Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。
-
-```shell
-kubectl apply -k .
-```
-
-出力は次のようになります。
-
-```
-secret/db-user-pass-dddghtt9b5 created
-```
-
-{{< note >}}
-Secretが生成されるとき、Secretのデータからハッシュ値が算出され、Secretの名称にハッシュ値が加えられます。
-これはデータが更新されたときに毎回新しいSecretが生成されることを保証します。
-{{< /note >}}
-
-#### Secretのデコード
-
-Secretは`kubectl get secret`を実行することで取得可能です。
-例えば、前のセクションで作成したSecretは次のコマンドを実行することで参照できます。
-
-```shell
-kubectl get secret mysecret -o yaml
-```
-
-出力は次のようになります。
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  creationTimestamp: 2016-01-22T18:41:56Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "164619"
-  uid: cfee02d6-c137-11e5-8d73-42010af00002
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-`password`フィールドをデコードします。
-
-```shell
-echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
-```
-
-出力は次のようになります。
-
-```
-1f2d1e2e67df
-```
-
-#### Secretの編集
 
 既存のSecretは次のコマンドで編集することができます。
 
@@ -491,7 +391,7 @@ Podに複数のコンテナがある場合、それぞれのコンテナが`volu
 #### Secretのキーの特定のパスへの割り当て
 
 Secretのキーが割り当てられるパスを制御することができます。
-それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定てきます。
+それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定できます。
 
 ```yaml
 apiVersion: v1
@@ -668,32 +568,6 @@ Secretはwatch（デフォルト）、TTLベース、単に全てのリクエス
 Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。
 {{< /note >}}
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
-
-Kubernetesのアルファ機能である _Immutable Secrets and ConfigMaps_ は各SecretやConfigMapが不変であると設定できるようにします。
-Secretを広範に利用しているクラスター（PodにマウントされているSecretが1万以上）においては、データが変更されないようにすることで次のような利点が得られます。
-
-- 意図しない（または望まない）変更によってアプリケーションの停止を引き起こすことを防ぎます
-- 不変であると設定されたSecretの監視を停止することにより、kube-apiserverの負荷が著しく軽減され、クラスターのパフォーマンスが改善されます
-
-この機能を利用するには、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretまたはConfigMapの`immutable`フィールドに`true`を指定します。例えば、次のようにします。
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  ...
-data:
-  ...
-immutable: true
-```
-
-{{< note >}}
-一度SecretやConfigMapを不変であると設定すると、この変更を戻すことや`data`フィールドの内容を書き換えることは _できません_ 。
-Secretを削除して、再生成することだけができます。
-既存のPodは削除されたSecretへのマウントポイントを持ち続けるため、Podを再生成することが推奨されます。
-{{< /note >}}
-
 ### Secretを環境変数として使用する {#using-secrets-as-environment-variables}
 
 SecretをPodの{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として使用するには、
@@ -753,6 +627,32 @@ echo $SECRET_PASSWORD
 1f2d1e2e67df
 ```
 
+## Immutable Secrets {#secret-immutable}
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecretsとConfigMapsをimutableとして設定するオプションを提供します。Secret（少なくとも数万の、SecretからPodへの一意のマウント）を広範囲に使用するクラスターの場合、データの変更を防ぐことには次の利点があります。
+
+- アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
+- imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。
+
+この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+{{< note >}}
+SecretまたはConfigMapがimutableとしてマークされると、この変更を元に戻したり、`data`フィールドの内容を変更したりすることは*できません*。Secretを削除して再作成することしかできません。
+既存のPodは、削除されたSecretへのマウントポイントを維持します。これらのPodを再作成することをお勧めします。
+{{< /note >}}
+
+
+
 ### imagePullSecretsを使用する {#using-imagepullsecrets}
 
 `imagePullSecrets`フィールドは同一のネームスペース内のSecretの参照のリストです。
@@ -1028,8 +928,8 @@ kubectl apply -k .
 
 2つのサービスアカウントを使用すると、ベースのPod仕様をさらに単純にすることができます。
 
-1. `prod-user` と `prod-db-secret`
+1. `prod-user`と`prod-db-secret`
-1. `test-user` と `test-db-secret`
+1. `test-user`と`test-db-secret`
 
 簡略化されたPod仕様は次のようになります。
 
@@ -1155,3 +1055,10 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
  - Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。
  - 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。
  単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。
+
+
+## {{% heading "whatsnext" %}}
+
+- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ
+- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ
+- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ

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

@@ -18,7 +18,7 @@ no_list: true
 
 <!-- body -->
 
-## コンテナイメージ
+## コンテナイメージ {#container-images}
 [コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
 
 設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。

content/ja/docs/concepts/containers/container-lifecycle-hooks.md

@@ -30,11 +30,11 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
 
 `PreStop`
 
-このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
+このフックは、APIからの要求、またはliveness probeの失敗、プリエンプション、リソース競合などの管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。
-これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。
+これはブロッキング、つまり同期的であるため、コンテナを停止する信号が送信される前に完了する必要があります。
 ハンドラーにパラメーターは渡されません。
 
-終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
+終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。
 
 ### フックハンドラーの実装
 
@@ -47,27 +47,32 @@ Angularなどのコンポーネントライフサイクルフックを持つ多
 
 ### フックハンドラーの実行
 
-コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはそのフック用に登録されたコンテナ内のハンドラーを実行します。
+コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはフックアクションにしたがってハンドラーを実行します。
+`exec`と`tcpSocket`はコンテナの中で実行され、`httpGet`はkubeletプロセスによって実行されます。
 
 フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。
 これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。
 しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。
 
-その振る舞いは `PreStop`フックに似ています。
+`PreStop`フックはコンテナを停止する信号から非同期で実行されるのではなく、信号が送られる前に実行を完了する必要があります。
-実行中にフックがハングした場合、Podフェーズは`Terminating`状態に留まり、Podの`terminationGracePeriodSeconds`が終了した後に終了します。
+もし`PreStop`フックが実行中にハングした場合、Podは`Terminating`状態になり、
-`PostStart`または`PreStop`フックが失敗した場合、コンテナを強制終了します。
+`terminationGracePeriodSeconds`の時間切れで強制終了されるまで続きます。
+この猶予時間は、`PreStop`フックが実行され正常にコンテナを停止できるまでの合計時間に適用されます。
+例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら２つの実行にかかる合計時間(55+10)よりも短いからです。
+
+`PostStart`または`PreStop`フックが失敗した場合、コンテナは強制終了します。
 
 ユーザーはフックハンドラーをできるだけ軽量にするべきです。
-ただし、コンテナを停止する前に状態を保存する場合など、長時間実行されるコマンドが意味をなす場合があります。
+ただし、コンテナを停止する前に状態を保存するなどの場合は、長時間のコマンド実行が必要なケースもあります。
 
-### フック配送保証
+### フック配信保証
 
-フックの配送は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
+フックの配信は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。
 これを正しく処理するのはフックの実装次第です。
 
-通常、単一の配送のみが行われます。
+通常、1回の配信のみが行われます。
 たとえば、HTTPフックレシーバーがダウンしていてトラフィックを受け取れない場合、再送信は試みられません。
-ただし、まれに二重配送が発生することがあります。
+ただし、まれに二重配信が発生することがあります。
 たとえば、フックの送信中にkubeletが再起動した場合、kubeletが起動した後にフックが再送信される可能性があります。
 
 ### フックハンドラーのデバッグ
@@ -101,4 +106,3 @@ Events:
 * [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細
 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
 
-

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

@@ -48,10 +48,9 @@ weight: 10
 
 `imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。
 
-## マニフェストを使ったマルチアーキテクチャイメージ
+## イメージインデックスを使ったマルチアーキテクチャイメージ
 
-コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。
+コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージインデックス](https://github.com/opencontainers/image-spec/blob/master/image-index.md)も提供する事ができます。イメージインデックスはコンテナのアーキテクチャ固有バージョンに関する複数の[イメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を指すことができます。イメージインデックスの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
-マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。
 
 Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。
 
@@ -179,7 +178,7 @@ Node構成を制御できる場合、この方法が適しています。
 
 すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。
 
-### PodでImagePullSecretsを指定する
+### PodでimagePullSecretsを指定する
 
 {{< note >}}
 この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。
@@ -187,7 +186,7 @@ Node構成を制御できる場合、この方法が適しています。
 
 KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。
 
-#### Docker Configを利用してSecretを作成する。
+#### Dockerの設定を利用してSecretを作成する。
 
 適切な大文字の値を置き換えて、次のコマンドを実行します。
 

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

@@ -140,7 +140,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
+Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。
 Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです)
 
 PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。
@@ -149,7 +149,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ
 
 ## {{% heading "whatsnext" %}}
 
-- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
+- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
-- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
-- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む
+- [Podオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む
 - [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)

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

@@ -105,7 +105,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 ### APIアクセス拡張 {#api-access-extensions}
 
-リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。
 
 これらの各ステップごとに拡張ポイントが用意されています。
 

content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -14,7 +14,7 @@ weight: 10
 
 ## カスタムリソース
 
-*リソース* は、[Kubernetes API](/docs/reference/using-api/api-overview/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
+*リソース* は、[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。
 
 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
 

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

@@ -107,7 +107,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま
 
 ### APIアクセスエクステンション
 
-リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。
 
 これらの各ステップごとに拡張ポイントが用意されています。
 

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

@@ -27,7 +27,7 @@ Kubernetesは自動化のために設計されています。追加の作業、
 ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。
 
 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
-オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
+オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
 
 ## オペレーターの例 {#example}
 
@@ -90,7 +90,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
   * [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います
   * [kubebuilder](https://book.kubebuilder.io/)を使います
   * [Metacontroller](https://metacontroller.app/)を自分で実装したWebHooksと一緒に使います
-  * [Operator Framework](https://github.com/operator-framework/getting-started)を使います
+  * [Operator Framework](https://operatorframework.io)を使います
 * 自前のオペレーターを他のユーザーのために[公開](https://operatorhub.io/)します
 * オペレーターパターンを紹介している[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

@@ -17,7 +17,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。
 
 すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。
 
-![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png)
+![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg)
 
 
 

content/ja/docs/concepts/overview/kubernetes-api.md

@@ -18,22 +18,13 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな
 
 Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
 
-APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。
+ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
+RESTコールを利用して直接APIにアクセスすることも可能です。
+
+Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。
 
 <!-- body -->
 
-## APIの変更
-
-成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
-したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
-Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。
-
-基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
-リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。
-
-互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。
-
-
 ## OpenAPI 仕様 {#api-specification}
 
 完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。
@@ -43,6 +34,7 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp
 
 
 <table>
+  <caption style="display:none">OpenAPI v2クエリの有効なリクエストヘッダー値</caption>
   <thead>
      <tr>
         <th>Header</th>
@@ -70,74 +62,55 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp
         <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パッケージ内に配置されています。
+Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しています。このフォーマットに関しては、[Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/des ign-proposals/api-machinery/protobuf.md)デザイン提案を参照してください。また、各スキーマのInterface Definition Language（IDL）ファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。
-
-## APIバージョニング
-
-フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。
-
-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)に記載されています。下記に簡潔にまとめます:
-
-- アルファレベル(版):
-  - バージョン名に`alpha`を含みます(例、`v1alpha1`)。
-  - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。
-  - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。
-  - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。
-  - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。
-- ベータレベル(版):
-  - バージョン名に`beta`を含みます(例、`v2beta3`)。
-  - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。
-  - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。
-  - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。
-  - 今後のリリースで、互換性の無い変更が行われる可能性があるため、ビジネスクリティカルな場面以外での利用を推奨します。もし複数のクラスターを持っており、それぞれ個別にアップグレードが可能な場合、この制限の影響を緩和できるかもしれません。
-  - **是非ベータ機能を試して、フィードバックをください！ベータから安定版になってしまうと、より多くの変更を加えることが難しくなってしまいます。**
-- 安定版:
-  - バージョン名は`vX`のようになっており、`X`は整数です。
-  - 安定版の機能は、今後のリリースバージョンにも適用されます。
-
-## APIグループ {#api-groups}
-
-APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。
-APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。
-
-クラスターにはいくつかのAPIグループがあります:
-
-1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。
-
-1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。
-
-[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります:
-
-1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。
-1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。
-
-## APIグループの有効化、無効化
-
-いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。
-
-`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。
-
-{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}}
 
 ## 永続性
 
 KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。
 
+## APIグループとバージョニング
+
+フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。
+
+APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。
+
+APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/docs/reference/using-api/#api-groups)を実装しました。
+
+APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。
+
+例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。
+
+## APIの変更
+
+成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。
+したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。
+Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊 _しないこと_ 、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。
+
+基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。
+リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。
+
+Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。
+
+{{< note >}}
+Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。アルファAPIバージョンを使っている場合、クラスタのアップグレードやAPIが変更された場合に備えて、Kubernetesのリリースノートを確認してください。
+{{< /note >}}
+
+APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/docs/reference/using-api/#api-versioning)を参照してください。
+
+## APIの拡張
+
+Kubernetes APIは2つの方法で拡張できます。
+
+1. [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)は、APIサーバーが選択したリソースAPIをどのように提供するかを宣言的に定義します。
+1. [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を実装することでKubernetes APIを拡張することもできます。
+
 
 ## {{% heading "whatsnext" %}}
 
-[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
+- 自分自身で[カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)を追加してKubernetes APIを拡張する方法について学んでください。
-
+- [Kubernetes APIのアクセス制御](/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。
-全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。
+- [APIリファレンス](/ja/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。
-
+- [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か, どのようにAPIを変更するかについて学んでください。
-APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。

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

@@ -8,6 +8,8 @@ weight: 10
 card:
   name: concepts
   weight: 10
+sitemap:
+  priority: 0.9
 ---
 
 <!-- overview -->
@@ -33,7 +35,7 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ
 
 各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。
 
-**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
+**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPUの共有、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
 
 コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。
 

content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -72,8 +72,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場
 
 
 
-* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。
 * 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。
-* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。
+* Kubernetesの[コントローラー](/ja/docs/concepts/architecture/controller/)を学びましょう。
-
+* [Using the Kubernetes API](/docs/reference/using-api/)はこのページでは取り上げていない他のAPIについて説明します。
 

content/ja/docs/concepts/overview/working-with-objects/labels.md

@@ -151,10 +151,11 @@ partition
 !partition
 ```
 
-最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。  
+* 最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。  
-第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。  
+* 第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。  
-第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。  
+* 第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。  
-第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。  
+* 第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。  
+
 同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。  
 *集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。  
 
@@ -198,7 +199,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 ```
 
 ### APIオブジェクトに参照を設定する
-[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。  
+[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/)のような他のリソースのセットを指定するのにも使われます。  
 
 #### ServiceとReplicationController
 `Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。  

content/ja/docs/concepts/overview/working-with-objects/namespaces.md

@@ -24,8 +24,6 @@ Namespaceは名前空間のスコープを提供します。リソース名は
 
 Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。)
 
-Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。
-
 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。
 同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。
 

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

@@ -15,7 +15,7 @@ weight: 10
 
 <!-- body -->
 
-`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。
+`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、名前空間内のリソースによって消費されるコンピュートリソースの総量を制限できます。
 
 リソースクォータは下記のように働きます。
 
@@ -25,7 +25,7 @@ weight: 10
 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
 - `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)である必要があります.
+ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
 
 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。
 
@@ -40,7 +40,7 @@ weight: 10
 
 多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。
 
-特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。
+特定の名前空間にResourceQuotaがあるとき、そのリソースクォータはその名前空間に適用されます。
 
 ## リソースクォータの計算
 
@@ -55,6 +55,9 @@ weight: 10
 | `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 |
 | `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 |
 | `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 |
+| `hugepages-<size>` | 停止していない状態の全てのPodで, 指定されたサイズのHuge Pageリクエスト数がこの値を超えることができません。 |
+| `cpu` | `requests.cpu`と同じ。 |
+| `memory` | `requests.memory`と同じ。 |
 
 ### 拡張リソースのためのリソースクォータ
 
@@ -79,8 +82,8 @@ GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で
 | --------------------- | ----------------------------------------------------------- |
 | `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 |
 | `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名`<storage-class-name>`に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名`<storage-class-name>`に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
 
 例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。
 
@@ -93,12 +96,14 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 |
 | `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 |
+| `ephemeral-storage` | `requests.ephemeral-storage`と同じ。 |
 
 ## オブジェクト数に対するクォータ
 
-Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。
+下記のシンタックスを使用して、名前空間に紐づいた全ての標準であるリソースタイプの中の特定のリソースの総数に対するリソースクォータを設定できます。
 
-* `count/<resource>.<group>`
+* `count/<resource>.<group>` コアでないグループのリソース用
+* `count/<resource>` コアグループのリソース用
 
 オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。
 
@@ -112,13 +117,12 @@ Kubernetes v1.9では下記のシンタックスを使用して、名前空間
 * `count/statefulsets.apps`
 * `count/jobs.batch`
 * `count/cronjobs.batch`
-* `count/deployments.extensions`
 
-Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
+カスタムリソースに対して同じシンタックスを使用できます。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。
 
-`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。
+`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります。適切に設定されていないCronJobから保護するためにジョブのクォータを設定できます。名前空間内で大量のJobを作成するCronJobは、サービスを利用不可能にする可能性があります。
 
-Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。
+また、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能です。
 
 下記のタイプのリソースがサポートされています。
 
@@ -128,7 +132,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
 | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 |
 | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。  |
 | `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 |
-| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 |
+| `resourcequotas` | 名前空間内で存在可能なResourceQuotaの総数。 |
 | `services` | 名前空間内で存在可能なServiceの総数。 |
 | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 |
 | `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 |
@@ -138,7 +142,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
 
 ## クォータのスコープについて
 
-各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。
+各リソースクォータには関連する`scope`のセットを関連づけることができます。クォータは、列挙されたscopeの共通部分と一致する場合にのみリソースの使用量を計測します。
 
 スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。
 
@@ -148,27 +152,72 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース
 | `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
 | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
 | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
+| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
 
-`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods`
+`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します:
 
-`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
-
-* `cpu`
-* `limits.cpu`
-* `limits.memory`
-* `memory`
 * `pods`
+
+`Terminating`、`NotTerminating`、`NotBestEffort`、`PriorityClass`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します:
+
+* `pods`
+* `cpu`
+* `memory`
 * `requests.cpu`
 * `requests.memory`
+* `limits.cpu`
+* `limits.memory`
+
+同じクォータで`Terminating`と`NotTerminating`の両方のスコープを指定することはできず、また同じクォータで`BestEffort`と`NotBestEffort`の両方のスコープを指定することもできないことに注意してください。
+
+`scopeSelector`は`operator` フィールドにおいて下記の値をサポートしています。:
+
+* `In`
+* `NotIn`
+* `Exists`
+* `DoesNotExist`
+
+`scopeSelector`の定義において`scopeName`に下記のいずれかの値を使用する場合、`operator`に`Exists`を指定してください。 
+
+* `Terminating`
+* `NotTerminating`
+* `BestEffort`
+* `NotBestEffort`
+
+`operator`が`In`または`NotIn`の場合、`values`フィールドには少なくとも1つの値が必要です。例えば以下のように記述します：
+
+```yaml
+  scopeSelector:
+    matchExpressions:
+      - scopeName: PriorityClass
+        operator: In
+        values:
+          - middle
+```
+
+`operator`が`Exists`または`DoesNotExist`の場合、`values`フィールドは指定*しないでください*。
 
 ### PriorityClass毎のリソースクォータ
 
-{{< feature-state for_k8s_version="v1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}
 
 Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
 
 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。
 
+リソースクォータが`scopeSelector`フィールドを使用して優先度クラスに対してスコープされる場合、リソースクォータのオプジェクトは、次のリソースのみトラッキングするように制限されます:
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
 この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。
 
 - クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。
@@ -230,7 +279,7 @@ items:
 kubectl create -f ./quota.yml
 ```
 
-```shell
+```
 resourcequota/pods-high created
 resourcequota/pods-medium created
 resourcequota/pods-low created
@@ -242,7 +291,7 @@ resourcequota/pods-low created
 kubectl describe quota
 ```
 
-```shell
+```
 Name:       pods-high
 Namespace:  default
 Resource    Used  Hard
@@ -305,7 +354,7 @@ kubectl create -f ./high-priority-pod.yml
 kubectl describe quota
 ```
 
-```shell
+```
 Name:       pods-high
 Namespace:  default
 Resource    Used  Hard
@@ -333,13 +382,6 @@ memory      0     20Gi
 pods        0     10
 ```
 
-`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。
-
-* `In`
-* `NotIn`
-* `Exist`
-* `DoesNotExist`
-
 ## リクエスト vs リミット
 
 コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。
@@ -400,7 +442,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
 kubectl get quota --namespace=myspace
 ```
 
-```shell
+```
 NAME                    AGE
 compute-resources       30s
 object-counts           32s
@@ -410,7 +452,7 @@ object-counts           32s
 kubectl describe quota compute-resources --namespace=myspace
 ```
 
-```shell
+```
 Name:                    compute-resources
 Namespace:               myspace
 Resource                 Used  Hard
@@ -426,7 +468,7 @@ requests.nvidia.com/gpu  0     4
 kubectl describe quota object-counts --namespace=myspace
 ```
 
-```shell
+```
 Name:                   object-counts
 Namespace:              myspace
 Resource                Used    Hard
@@ -447,40 +489,39 @@ kubectl create namespace myspace
 ```
 
 ```shell
-kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
 ```
 
 ```shell
-kubectl create deployment nginx --image=nginx --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
-kubectl scale deployment nginx --replicas=2 --namespace=myspace
 ```
 
 ```shell
 kubectl describe quota --namespace=myspace
 ```
 
-```shell
+```
 Name:                         test
 Namespace:                    myspace
 Resource                      Used  Hard
 --------                      ----  ----
-count/deployments.extensions  1     2
+count/deployments.apps        1     2
 count/pods                    2     3
-count/replicasets.extensions  1     4
+count/replicasets.apps        1     4
 count/secrets                 1     4
 ```
 
 ## クォータとクラスター容量
 
-`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
+ResourceQuotaはクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。
 
 下記のようなより複雑なポリシーが必要な状況があります。
 
-  - 複数チーム間でクラスターリソースの総量を分けあう。
+- 複数チーム間でクラスターリソースの総量を分けあう。
-  - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
+- 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。
-  - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
+- 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。
 
-このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。
+このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、ResourceQuotaをビルディングブロックのように使用して実装できます。
 
 リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。
 
@@ -490,10 +531,8 @@ count/secrets                 1     4
 
 このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。
 
-これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
+これを実施するには、`kube-apiserver`の`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。
 
-{{< tabs name="example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
 apiVersion: apiserver.config.k8s.io/v1
 kind: AdmissionConfiguration
@@ -509,27 +548,6 @@ plugins:
         operator: In
         values: ["cluster-services"]
 ```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。
-apiVersion: apiserver.k8s.io/v1alpha1
-kind: AdmissionConfiguration
-plugins:
-- name: "ResourceQuota"
-  configuration:
-    # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。
-    apiVersion: resourcequota.admission.k8s.io/v1beta1
-    kind: Configuration
-    limitedResources:
-    - resource: pods
-      matchScopes:
-      - scopeName: PriorityClass
-        operator: In
-        values: ["cluster-services"]
-```
-{{% /tab %}}
-{{< /tabs >}}
 
 なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。
 
@@ -541,14 +559,9 @@ plugins:
         values: ["cluster-services"]
 ```
 
-さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
-
-## 例
-
-[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
-
-
 ## {{% heading "whatsnext" %}}
 
 - さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。
-
+- [リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。
+- [優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。
+- [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)を参照してください。

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

@@ -66,17 +66,7 @@ nodeSelectorを以下のように追加します:
 ## 補足: ビルトインNodeラベル {#built-in-node-labels}
 
 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
-以下のようなラベルが該当します。
+これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。
-
-* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
-* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
-* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
-* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
 
 {{< note >}}
 これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
@@ -93,7 +83,7 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー
 `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
 Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。
 
-1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。
+1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。
 2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
 

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

@@ -26,11 +26,11 @@ kube-schedulerは、もし希望するのであれば自分自身でスケジュ
 kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。
 しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。
 
-クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。
+クラスター内でPodに対する割り当て要求を満たしたNodeは _割り当て可能_ なNodeと呼ばれます。
 もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。
 
 スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。
-スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
+スケジューラーは _binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
 
 スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。
 
@@ -50,65 +50,10 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
 
 最後に、kube-schedulerは最も高いランクのNodeに対してPodを割り当てます。もし同一のスコアのNodeが複数ある場合は、kube-schedulerがランダムに1つ選択します。
 
-### デフォルトのポリシーについて
+スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。
 
-kube-schedulerは、デフォルトで用意されているスケジューリングポリシーのセットを持っています。
+1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。
-
+1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。
-### フィルタリング
-
-- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。
-
-- `PodFitsHost`: Podがそのホスト名において特定のNodeを指定しているかをチェックします。
-
-- `PodFitsResources`: Nodeに、Podが要求するリソース(例: CPUとメモリー)が利用可能かどうかをチェックします。
-
-- `PodMatchNodeSelector`: PodのNodeSelectorが、Nodeのラベルにマッチするかどうかをチェックします。
-
-- `NoVolumeZoneConflict`: Podが要求するVolumeがNode上で利用可能かを、障害が発生しているゾーンを考慮して評価します。
-
-- `NoDiskConflict`: NodeのVolumeがPodの要求を満たし、すでにマウントされているかどうかを評価します。
-
-- `MaxCSIVolumeCount`: CSI Volumeをいくつ割り当てるべきか決定し、それが設定された上限を超えるかどうかを評価します。
-
-- `CheckNodeMemoryPressure`: もしNodeがメモリーの容量が逼迫している場合、また設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
-
-- `CheckNodePIDPressure`: もしNodeのプロセスIDが枯渇しそうになっていた場合や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
-
-- `CheckNodeDiskPressure`: もしNodeのストレージが逼迫している場合(ファイルシステムの残り容量がほぼない場合)や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
-
-- `CheckNodeCondition`: Nodeは、ファイルシステムの空き容量が完全になくなった場合、ネットワークが利用不可な場合、kubeletがPodを稼働させる準備をできていない場合などに、その状況を通知できます。Nodeがこの状況下かつ設定された例外がない場合、Podは該当のNodeにスケジュールされません。
-
-- `PodToleratesNodeTaints`: PodのTolerationがNodeのTaintを許容できるかチェックします。
-
-- `CheckVolumeBinding`: Podが要求するVolumeの要求を満たすか評価します。これはPersistentVolumeClaimがバインドされているかに関わらず適用されます。
-
-### スコアリング
-
-- `SelectorSpreadPriority`:　同一のService、StatefulSetや、ReplicaSetに属するPodを複数のホストをまたいで稼働させます。
-
-- `InterPodAffinityPriority`: weightedPodAffinityTermの要素をイテレートして合計を計算したり、もし一致するPodAffinityTermがNodeに適合している場合は、"重み"を合計値に足したりします。:最も高い合計値を持つNode(複数もあり)が候補となります。
-
-- `LeastRequestedPriority`: 要求されたリソースがより低いNodeを優先するものです。言い換えると、Nodeに多くのPodが稼働しているほど、Podが使用するリソースが多くなり、その要求量が低いNodeが選択されます。
-
-- `MostRequestedPriority`: 要求されたリソースがより多いNodeを優先するものです。このポリシーは、ワークロードの全体セットを実行するために必要な最小数のNodeに対して、スケジュールされたPodを適合させます。　
-
-- `RequestedToCapacityRatioPriority`: デフォルトのリソーススコアリング関数を使用して、requestedToCapacityベースのResourceAllocationPriorityを作成します。
-
-- `BalancedResourceAllocation`: バランスのとれたリソース使用量になるようにNodeを選択します。
-
-- `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なる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のランクを調整します。
-
-- `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。
-
-- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
-
-- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
-
-- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
 
 
 ## {{% heading "whatsnext" %}}
@@ -118,4 +63,8 @@ kube-schedulerは、デフォルトで用意されているスケジューリン
 * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
 * [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
 * [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
-* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。
+* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
+* ボリュームを使用するPodのスケジューリングについて以下で学んでください。
+  * [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
+  * [ストレージ容量の追跡](/ja//docs/concepts/storage/storage-capacity/)
+  * [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)

content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -1,7 +1,7 @@
 ---
 title: スケジューラーのパフォーマンスチューニング
 content_type: concept
-weight: 70
+weight: 80
 ---
 
 <!-- overview -->
@@ -15,12 +15,44 @@ weight: 70
 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。
 
 
-
 <!-- body -->
 
-## スコア付けするノードの割合
+大規模クラスターでは、レイテンシー(新規Podをすばやく配置)と精度(スケジューラーが不適切な配置を行うことはめったにありません)の間でスケジューリング結果を調整するスケジューラーの動作をチューニングできます。
 
-Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するためのメカニズムがあります。このメカニズムでは100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。
+このチューニング設定は、kube-scheduler設定の`percentageOfNodesToScore`で設定できます。KubeSchedulerConfiguration設定は、クラスター内のノードにスケジュールするための閾値を決定します。
+
+### 閾値の設定
+
+`percentageOfNodesToScore`オプションは、0から100までの数値を受け入れます。0は、kube-schedulerがコンパイル済みのデフォルトを使用することを示す特別な値です。
+`percentageOfNodesToScore`に100より大きな値を設定した場合、kube-schedulerの挙動は100を設定した場合と同様となります。
+
+この値を変更するためには、kube-schedulerの設定ファイル(これは`/etc/kubernetes/config/kube-scheduler.yaml`の可能性が高い)を編集し、スケジューラーを再起動します。
+
+この変更をした後、
+
+```bash
+kubectl get pods -n kube-system | grep kube-scheduler
+```
+
+を実行して、kube-schedulerコンポーネントが正常であることを確認できます。
+
+## ノードへのスコア付けの閾値 {#percentage-of-nodes-to-score}
+
+スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。
+
+クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
+
+[スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。
+
+### デフォルトの閾値
+
+閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。
+
+つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。
+
+スケジューラーにクラスター内のすべてのノードに対してスコア付けをさせる場合は、`percentageOfNodesToScore`の値に100を設定します。
+
+## 例
 
 `percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。
 
@@ -35,22 +67,23 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```
 
+## percentageOfNodesToScoreのチューニング
+
+`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。
+
 {{< note >}}
-割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。
+割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
+
+小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
+
+クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。
 {{< /note >}}
 
-**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。
+この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。
 
+kube-schedulerが頻繁に不適切なPodの配置を行わないよう、`percentageOfNodesToScore`をかなり低い値を設定することは避けるべきです。スケジューラのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でない場合を除いて、10%未満に設定することは避けてください。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
 
-### percentageOfNodesToScoreのチューニング
+## スケジューラーはどのようにノードを探索するか {#how-the-scheduler-iterates-over-nodes}
-
-`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。
-
-この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
-
-クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。
-
-### スケジューラーはどのようにノードを探索するか
 
 このセクションでは、この機能の内部の詳細を理解したい人向けになります。
 

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

@@ -22,30 +22,30 @@ Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubec
 例えば、次のコマンドは
 
 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```
 
-`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。
+`node1`にtaintを設定します。このtaintのキーは`key1`、値は`value1`、taintの効果は`NoSchedule`です。
 これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。
 
 上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```
 
 PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Equal"
-  value: "value"
+  value: "value1"
   effect: "NoSchedule"
 ```
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Exists"
   effect: "NoSchedule"
 ```
@@ -67,7 +67,7 @@ tolerationがtaintと合致するのは、`key`と`effect`が同一であり、
 
 空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。
 
-空の`effect`は`key`が一致する全てのeffectと合致します。
+空の`effect`は`key1`が一致する全てのeffectと合致します。
 
 {{< /note >}}
 

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

@@ -82,12 +82,12 @@ Kubernetesを保護する為には２つの懸念事項があります。
 
 ワークロードセキュリティに関する懸念事項 | 推奨事項 |
 ------------------------------ | --------------------- |
-RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/
-認証 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ |
+認証 | https://kubernetes.io/docs/concepts/security/controlling-access/ |
 アプリケーションのSecret管理(およびetcdへの保存時に暗号化) | https://kubernetes.io/ja/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ |
 PodSecurityPolicy | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ |
 Quality of Service (およびクラスターリソース管理) | https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/ |
-NetworkPolicy | https://kubernetes.io/docs/concepts/services-networking/network-policies/ |
+NetworkPolicy | https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/ |
 Kubernetes IngressのTLS | https://kubernetes.io/ja/docs/concepts/services-networking/ingress/#tls |
 
 
@@ -123,10 +123,10 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合
 
 関連するKubernetesセキュリティについて学びます。
 
-* [Podのセキュリティ基準](/docs/concepts/security/pod-security-standards/)
+* [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)
-* [PodのNetworkPolicy](/docs/concepts/services-networking/network-policies/)
+* [Podのネットワークポリシー]](/ja/docs/concepts/services-networking/network-policies/)
+* [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access)
 * [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/)
-* [APIアクセスコントロール](/docs/reference/access-authn-authz/controlling-access/)
 * コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/)
 * [Kubernetes Secret](/ja/docs/concepts/configuration/secret/)

content/ja/docs/concepts/services-networking/dns-pod-service.md

@@ -122,6 +122,29 @@ spec:
 A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。
 {{< /note >}}
 
+### PodのsetHostnameAsFQDNフィールド
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+
+**前提条件**: {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に対して`SetHostnameAsFQDN`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
+
+Podが完全修飾ドメイン名(FQDN)を持つように構成されている場合、そのホスト名は短いホスト名です。
+例えば、FQDNが`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`のPodがある場合、
+デフォルトではそのPod内の`hostname`コマンドは`busybox-1`を返し、`hostname --fqdn`コマンドはFQDNを返します。
+
+Podのspecで`setHostnameAsFQDN: true`を設定した場合、そのPodの名前空間に対してkubeletはPodのFQDNをホスト名に書き込みます。
+この場合、`hostname`と`hostname --fqdn`の両方がPodのFQDNを返します。
+
+{{< note >}}
+Linuxでは、カーネルのホスト名のフィールド(`struct utsname`の`nodename`フィールド)は64文字に制限されています。
+
+Podがこの機能を有効にしていて、そのFQDNが64文字より長い場合、Podは起動に失敗します。
+Podは`Pending`ステータス(`kubectl`でみられる`ContainerCreating`)のままになり、「Podのホスト名とクラスタードメインからFQDNを作成できなかった」や、「FQDN`long-FQDN`が長すぎる(64文字が最大, 70文字が要求された)」などのエラーイベントが生成されます。
+
+このシナリオのユーザー体験を向上させる1つの方法は、[admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を作成して、ユーザーがDeploymentなどのトップレベルのオブジェクトを作成するときにFQDNのサイズを制御することです。
+{{< /note >}}
+
+
 ### PodのDNSポリシー
 
 DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。

content/ja/docs/concepts/services-networking/dual-stack.md

@@ -40,6 +40,7 @@ IPv4/IPv6デュアルスタックを有効にするには、クラスターの
 
    * kube-apiserver:
       * `--feature-gates="IPv6DualStack=true"`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>
    * kube-controller-manager:
       * `--feature-gates="IPv6DualStack=true"`
       * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
@@ -89,7 +90,7 @@ IPv6が有効になった外部ロードバランサーをサポートしてい
 
 ## 外向きのトラフィック {#egress-traffic}
 
-パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
+パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。
 
 ## 既知の問題
 

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

@@ -1,7 +1,7 @@
 ---
 title: EndpointSlice
 content_type: concept
-weight: 15
+weight: 35
 ---
 
 <!-- overview -->
@@ -14,13 +14,19 @@ weight: 15
 
 ## 動機
 
-Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
+Endpoint APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。
+残念ながら、Kubernetesクラスターや{{< glossary_tooltip text="Service" term_id="service" >}}が大規模になり、より多くのトラフィックを処理し、より多くのバックエンドPodに送信するようになるにしたがって、Endpoint APIの限界が明らかになってきました。
+最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。
 
-Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
+Serviceのすべてのネットワークエンドポイントが単一のEndpointリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。
 
 ## EndpointSliceリソース {#endpointslice-resource}
 
-Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。
+コントロールプレーンは、{{< glossary_tooltip text = "セレクター" term_id = "selector" >}}が指定されているKubernetes ServiceのEndpointSliceを自動的に作成します。
+これらのEndpointSliceには、Serviceセレクターに一致するすべてのPodへのリファレンスが含まれています。
+EndpointSliceは、プロトコル、ポート番号、およびサービス名の一意の組み合わせによってネットワークエンドポイントをグループ化します。
+EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
 
 一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。
 
@@ -47,9 +53,9 @@ endpoints:
       topology.kubernetes.io/zone: us-west2-a
 ```
 
-デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。
+デフォルトでは、コントロールプレーンはEndpointSliceを作成・管理し、それぞれのエンドポイント数が100以下になるようにします。`--max-endpoints-per-slice`{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}フラグを設定することで、最大1000個まで設定可能です。
 
-EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
+EndpointSliceは内部トラフィックのルーティング方法に関して、{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}に対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。
 
 ### アドレスの種類
 
@@ -59,9 +65,10 @@ EndpointSliceは次の3種類のアドレスをサポートします。
 * IPv6
 * FQDN (Fully Qualified Domain Name、完全修飾ドメイン名)
 
-### トポロジー
+### トポロジー {#topology}
 
-EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。
+EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。
+値が利用できる場合には、コントロールプレーンはEndpointSliceコントローラーに次のようなTopologyラベルを設定します。
 
 * `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。
 * `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。
@@ -71,25 +78,34 @@ EndpointSliceに属する各エンドポイントは、関連するトポロジ
 
 ### 管理
 
-EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
+ほとんどの場合、コントロールプレーン（具体的には、EndpointSlice {{< glossary_tooltip text = "コントローラー" term_id = "controller" >}}）は、EndpointSliceオブジェクトを作成および管理します。EndpointSliceには、サービスメッシュの実装など、他のさまざまなユースケースがあり、他のエンティティまたはコントローラーがEndpointSliceの追加セットを管理する可能性があります。
+
+複数のエンティティが互いに干渉することなくEndpointSliceを管理できるようにするために、KubernetesはEndpointSliceを管理するエンティティを示す`endpointslice.kubernetes.io/managed-by`という{{< glossary_tooltip term_id="label" text="ラベル" >}}を定義します。
+EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。
 
 ### 所有権
 
-ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
+ほとんどのユースケースでは、EndpointSliceはエンドポイントスライスオブジェクトがエンドポイントを追跡するServiceによって所有されます。
+これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。
 
-## EndpointSliceコントローラー
+### EndpointSliceのミラーリング
 
-EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。
+場合によっては、アプリケーションはカスタムEndpointリソースを作成します。これらのアプリケーションがEndpointリソースとEndpointSliceリソースの両方に同時に書き込む必要がないようにするために、クラスターのコントロールプレーンは、ほとんどのEndpointリソースを対応するEndpointSliceにミラーリングします。
 
-### EndpointSliceのサイズ
+コントロールプレーンは、次の場合を除いて、Endpointリソースをミラーリングします。
 
-デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。
+* Endpointリソースの`endpointslice.kubernetes.io/skip-mirror`ラベルが`true`に設定されています。
+* Endpointリソースが`control-plane.alpha.kubernetes.io/leader`アノテーションを持っています。
+* 対応するServiceリソースが存在しません。
+* 対応するServiceリソースには、nil以外のセレクターがあります。
+
+個々のEndpointリソースは、複数のEndpointSliceに変換される場合があります。これは、Endpointリソースに複数のサブセットがある場合、または複数のIPファミリ（IPv4およびIPv6）を持つエンドポイントが含まれている場合に発生します。サブセットごとに最大1000個のアドレスがEndpointSliceにミラーリングされます。
 
 ### EndpointSliceの分散
 
-それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。
+それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointにグループ化される場合と同様です。
 
-コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
+コントロールプレーンはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。
 
 1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。
 2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。
@@ -101,8 +117,16 @@ EndpointSliceコントローラーは対応するEndpointSliceが最新の状態
 
 現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。
 
+### エンドポイントの重複
+
+EndpointSliceの変更の性質上、エンドポイントは同時に複数のEndpointSliceで表される場合があります。
+これは、さまざまなEndpointSliceオブジェクトへの変更が、さまざまな時間にKubernetesクライアントのウォッチ/キャッシュに到達する可能性があるために自然に発生します。
+EndpointSliceを使用する実装では、エンドポイントを複数のスライスに表示できる必要があります。
+エンドポイント重複排除を実行する方法のリファレンス実装は、`kube-proxy`の`EndpointSliceCache`実装にあります。
+
+
 ## {{% heading "whatsnext" %}}
 
-* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices)
+* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む
 

content/ja/docs/concepts/services-networking/ingress-controllers.md

@@ -11,47 +11,42 @@ Ingressリソースが動作するためには、クラスターでIngressコン
 
 `kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。
 
-プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。
+プロジェクトとしてのKubernetesは現在、[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)、[GCE](https://git.k8s.io/ingress-gce/README.md#readme)、および[nginx](https://git.k8s.io/ingress-nginx/README.md#readme)のIngressコントローラーをサポート・保守しています。
-
-
 
 <!-- body -->
 
 ## 追加のコントローラー {#additional-controllers}
 
-* [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コントローラーです。
+{{% thirdparty-content %}}
-* [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](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。
+* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は、[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を設定するIngressコントローラーです。
-* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。
+* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーです。
-* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
+* [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme)は、Citrix Application Delivery Controllerで動作します。
-* 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)を提供しています。
+* [Contour](https://projectcontour.io/)は、[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。
-* 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)を提供しています。
+* F5 BIG-IPの[Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)はF5 BIG-IPの仮想サーバー上でIngressの設定を可能にします。
-* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。
+* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、API Gateway機能を提供しています。
-* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。
+* [HAProxy Ingress](https://haproxy-ingress.github.io)は、[HAProxy](http://www.haproxy.org/#desc)用の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/)を参照してください。
+* [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)も、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。
-* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。
+* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。
-* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。
+* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。
-* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。
+* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。
-* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。
+* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://github.com/containous/traefik) proxy向けのIngressコントローラーです。
+* [Voyager](https://appscode.com/products/voyager)は、[HAProxy](http://www.haproxy.org/#desc)向けのIngressコントローラーです。
 
 ## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}
 
-[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
+[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定する必要があります。
 
 クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。
 
 理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。
 
-
 {{< note >}}
 Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。
 {{< /note >}}
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。
-* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細
+* [Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする](/ja/docs/tasks/access-application-cluster/ingress-minikube)。
-* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)

content/ja/docs/concepts/services-networking/ingress.md

@@ -5,7 +5,7 @@ weight: 40
 ---
 
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.1" state="beta" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}
 {{< glossary_definition term_id="ingress" length="all" >}}
 
 
@@ -23,17 +23,28 @@ weight: 40
 
 ## Ingressとは何か
 
-[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
+[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。
 
-```none
+全てのトラフィックを単一のServiceに送る単純なIngressの例を示します。
-    internet
-        |
-   [ Ingress ]
-   --|-----|--
-   [ Services ]
-```
 
-IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
+{{< mermaid >}}
+graph LR;
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress];
+  ingress-->|ルーティングルール|service[Service];
+  subgraph cluster[クラスター]
+  ingress;
+  service-->pod1[Pod];
+  service-->pod2[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service,pod1,pod2 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
+
+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タイプを一般的には使用します。
 
@@ -53,23 +64,7 @@ Ingressコントローラーのドキュメントを確認して、選択する
 
 Ingressリソースの最小構成の例は以下のとおりです。
 
-```yaml
+{{< codenew file="service/networking/minimal-ingress.yaml" >}}
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - 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コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
 
@@ -80,52 +75,106 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/
 各HTTPルールは以下の情報を含みます。
 
 * オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。
-* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
+* パスのリスト(例: `/testpath`)。各パスには`service.name`と`service.port.name`または`service.port.number`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。
-* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
+* バックエンドは[Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているようなService名とポート名の組み合わせ、または{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}による[カスタムリソースバックエンド](#resource-backend)です。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。
 
-Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
+Ingressコントローラーでは、`defaultBackend`が設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。
 
-### デフォルトのバックエンド
+### デフォルトのバックエンド {#default-backend}
 
-ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
+ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。`defaultBackend`は、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。
 
-IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
+HTTPリクエストがIngressオブジェクトのホスト名とパスの条件に1つも一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。
+
+### リソースバックエンド {#resource-backend}
+
+`Resource`バックエンドはIngressオブジェクトと同じnamespaceにある他のKubernetesリソースを指すObjectRefです。
+`Resource`はServiceの設定とは排他であるため、両方を指定するとバリデーションに失敗します。
+`Resource`バックエンドのよくある用途は、静的なアセットが入ったオブジェクトストレージを設定することです。
+
+{{< codenew file="service/networking/ingress-resource-backend.yaml" >}}
+
+上記のIngressを作成した後に、次のコマンドで参照することができます。
+
+```bash
+kubectl describe ingress ingress-resource-backend
+```
+
+```
+Name:             ingress-resource-backend
+Namespace:        default
+Address:
+Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
+Rules:
+  Host        Path  Backends
+  ----        ----  --------
+  *
+              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
+Annotations:  <none>
+Events:       <none>
+```
 
 ### パスのタイプ
 
-Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。
+Ingressのそれぞれのパスは対応するパスのタイプを持ちます。`pathType`が明示的に指定されていないパスはバリデーションに通らないでしょう。サポートされているパスのタイプは3種類あります。
 
-* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
+* `ImplementationSpecific`（実装に特有）: このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。
 
-* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。
+* `Exact`: 大文字小文字を区別して完全に一致するURLパスと一致します。
 
-* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
+* `Prefix`: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。
   
   {{< note >}}
   パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。
   {{< /note >}}
 
+### 例
+
+| タイプ | パス                            | リクエストパス                | 一致するか                           |
+|--------|---------------------------------|-------------------------------|--------------------------------------|
+| Prefix | `/`                             | （全てのパス）                | はい                                 |
+| Exact  | `/foo`                          | `/foo`                        | はい                                 |
+| Exact  | `/foo`                          | `/bar`                        | いいえ                               |
+| Exact  | `/foo`                          | `/foo/`                       | いいえ                               |
+| Exact  | `/foo/`                         | `/foo`                        | いいえ                               |
+| Prefix | `/foo`                          | `/foo`, `/foo/`               | はい                                 |
+| Prefix | `/foo/`                         | `/foo`, `/foo/`               | はい                                 |
+| Prefix | `/aaa/bb`                       | `/aaa/bbb`                    | いいえ                               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb`                    | はい                                 |
+| Prefix | `/aaa/bbb/`                     | `/aaa/bbb`                    | はい、末尾のスラッシュは無視         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/`                   | はい、末尾のスラッシュと一致         |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbb/ccc`                | はい、パスの一部と一致               |
+| Prefix | `/aaa/bbb`                      | `/aaa/bbbxyz`                 | いいえ、接頭辞と一致しない           |
+| Prefix | `/`, `/aaa`                     | `/aaa/ccc`                    | はい、接頭辞`/aaa`と一致             |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/aaa/bbb`                    | はい、接頭辞`/aaa/bbb`と一致         |
+| Prefix | `/`, `/aaa`, `/aaa/bbb`         | `/ccc`                        | はい、接頭辞`/`と一致                |
+| Prefix | `/aaa`                          | `/ccc`                        | いいえ、デフォルトバックエンドを使用 |
+| Mixed  | `/foo` (Prefix), `/foo` (Exact) | `/foo`                        | はい、Exactが優先                    |
+
 #### 複数のパスとの一致
 
 リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。
 
+## ホスト名のワイルドカード
+
+ホストは正確に一致する（例えば`foo.bar.com`）かワイルドカード（例えば`*.foo.com`）とすることができます。
+正確な一致ではHTTPヘッダーの`host`が`host`フィールドと一致することが必要です。
+ワイルドカードによる一致では、HTTPヘッダーの`host`がワイルドカードルールに沿って後方一致することが必要です。
+
+| Host        | Hostヘッダー      | 一致するか                                                  |
+| ----------- |-------------------| ------------------------------------------------------------|
+| `*.foo.com` | `bar.foo.com`     | 共通の接尾辞により一致                                      |
+| `*.foo.com` | `baz.bar.foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
+| `*.foo.com` | `foo.com`         | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする |
+
+{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}}
+
 ## Ingress Class
 
 Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。
 IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。
 
-```yaml
+{{< codenew file="service/networking/external-lb.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リソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。
 
@@ -137,7 +186,7 @@ Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールド
 Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。
 アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。
 
-### デフォルトのIngress Class
+### デフォルトのIngressClass {#default-ingress-class}
 
 特定のIngressClassをクラスターでのデフォルトとすることができます。
 IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。
@@ -148,20 +197,21 @@ IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノ
 
 ## Ingressのタイプ
 
-### 単一ServiceのIngress
+### 単一ServiceのIngress {#single-service-ingress}
+
 Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。
 
-{{< codenew file="service/networking/ingress.yaml" >}}
+{{< codenew file="service/networking/test-ingress.yaml" >}}
 
 `kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。
 
-```shell
+```bash
 kubectl get ingress test-ingress
 ```
 
 ```
-NAME           HOSTS     ADDRESS           PORTS     AGE
+NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
-test-ingress   *         203.0.113.123     80        59s
+test-ingress   external-lb   *       203.0.113.123   80      59s
 ```
 
 `203.0.113.123`はIngressコントローラーによって割り当てられたIPで、作成したIngressを利用するためのものです。
@@ -174,34 +224,29 @@ IngressコントローラーとロードバランサーがIPアドレス割り
 
 ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによってロードバランサーの数を少なくすることができます。例えば、以下のように設定します。
 
-```none
+{{< mermaid >}}
-foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
+graph LR;
-                                 / bar    service2:8080
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
-```
+  ingress-->|/foo|service1[Service service1:4200];
+  ingress-->|/bar|service2[Service service2:8080];
+  subgraph cluster[クラスター]
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 Ingressを以下のように設定します。
 
-```yaml
+{{< codenew file="service/networking/simple-fanout-example.yaml" >}}
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: simple-fanout-example
-  annotations:
-    nginx.ingress.kubernetes.io/rewrite-target: /
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - path: /foo
-        backend:
-          serviceName: service1
-          servicePort: 4200
-      - path: /bar
-        backend:
-          serviceName: service2
-          servicePort: 8080
-```
 
 Ingressを`kubectl apply -f`によって作成したとき:
 
@@ -220,8 +265,6 @@ Rules:
   foo.bar.com
                /foo   service1:4200 (10.8.0.90:4200)
                /bar   service2:8080 (10.8.0.91:8080)
-Annotations:
-  nginx.ingress.kubernetes.io/rewrite-target:  /
 Events:
   Type     Reason  Age                From                     Message
   ----     ------  ----               ----                     -------
@@ -232,75 +275,46 @@ IngressコントローラーはService(`service1`、`service2`)が存在する
 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。
 
 {{< note >}}
-使用する[Ingressコントローラー](/ja/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 >}}
 
 ### 名前ベースのバーチャルホスティング
 
 名前ベースのバーチャルホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。
 
-```none
+{{< mermaid >}}
-foo.bar.com --|                 |-> foo.bar.com service1:80
+graph LR;
-              | 178.91.123.132  |
+  client([クライアント])-. Ingress管理下の <br> ロードバランサー .->ingress[Ingress, 178.91.123.132];
-bar.foo.com --|                 |-> bar.foo.com service2:80
+  ingress-->|Host: foo.bar.com|service1[Service service1:80];
-```
+  ingress-->|Host: bar.foo.com|service2[Service service2:80];
+  subgraph cluster[クラスター]
+  ingress;
+  service1-->pod1[Pod];
+  service1-->pod2[Pod];
+  service2-->pod3[Pod];
+  service2-->pod4[Pod];
+  end
+  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
+  class client plain;
+  class cluster cluster;
+{{</ mermaid >}}
 
 以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。
 
-```yaml
+{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}}
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: foo.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: bar.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-```
 
 rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。
 
-例えば、以下のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
+例えば、以下のIngressは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。
 
-```yaml
+{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
-apiVersion: networking.k8s.io/v1beta1
-kind: Ingress
-metadata:
-  name: name-virtual-host-ingress
-spec:
-  rules:
-  - host: first.bar.com
-    http:
-      paths:
-      - backend:
-          serviceName: service1
-          servicePort: 80
-  - host: second.foo.com
-    http:
-      paths:
-      - backend:
-          serviceName: service2
-          servicePort: 80
-  - http:
-      paths:
-      - backend:
-          serviceName: service3
-          servicePort: 80
-```
 
 ### TLS
 
-TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。
+TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。Ingressは単一のTLSポートである443番ポートのみサポートし、IngressでTLS終端を行うことを想定しています。IngressからServiceやPodへのトラフィックは平文です。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。
 
 ```yaml
 apiVersion: v1
@@ -314,37 +328,25 @@ data:
 type: kubernetes.io/tls
 ```
 
-IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
+IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`https-example.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。
 
-```yaml
+{{< note >}}
-apiVersion: networking.k8s.io/v1beta1
+デフォルトルールではTLSが機能しない可能性があることに注意してください。
-kind: Ingress
+これは取り得る全てのサブドメインに対する証明書を発行する必要があるからです。
-metadata:
+そのため、`tls`セクションの`hosts`は`rules`セクションの`host`と明示的に一致する必要があります。
-  name: tls-example-ingress
+{{< /note >}}
-spec:
+
-  tls:
+{{< codenew file="service/networking/tls-example-ingress.yaml" >}}
-  - hosts:
-      - sslexample.foo.com
-    secretName: testsecret-tls
-  rules:
-  - host: sslexample.foo.com
-    http:
-      paths:
-      - path: /
-        backend:
-          serviceName: service1
-          servicePort: 80
-```
 
 {{< note >}}
 サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。
 {{< /note >}}
 
-### 負荷分散
+### 負荷分散 {#load-balancing}
 
 Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
 
-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によってヘルスチェックの機能が直接に公開されていない場合でも、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の更新
 
@@ -385,16 +387,22 @@ spec:
     http:
       paths:
       - backend:
-          serviceName: service1
+          service:
-          servicePort: 80
+            name: service1
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
   - host: bar.baz.com
     http:
       paths:
       - backend:
-          serviceName: service2
+          service:
-          servicePort: 80
+            name: service2
+            port:
+              number: 80
         path: /foo
+        pathType: Prefix
 ..
 ```
 
@@ -430,11 +438,7 @@ Events:
 
 ## アベイラビリティーゾーンをまたいだ障害について
 
-障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/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と関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。
 
 ## Ingressの代替案 {#alternatives}
 
@@ -447,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
 ## {{% heading "whatsnext" %}}
 * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
 * [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
-* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube)
+* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)

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

@@ -6,9 +6,17 @@ weight: 50
 
 <!-- overview -->
 
-ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。
+IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、{{<glossary_tooltip text="Pod" term_id="pod">}}がネットワークを介して多様な「エンティティ」(「Endpoint」や「Service」のようなKubernetesに含まれる特定の意味を持つ共通の用語との重複を避けるため、ここではエンティティという単語を使用します。)と通信する方法を指定できます。
 
-NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。
+Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。
+
+1. 許可されている他のPod(例外: Podはそれ自体へのアクセスをブロックできません)
+2. 許可されている名前空間
+3. IPブロック(例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。)
+
+Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{<glossary_tooltip text="セレクター" term_id="selector">}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。
+
+一方でIPベースのネットワークポリシーが作成されると、IPブロック(CIDRの範囲)に基づいてポリシーが定義されます。
 
 <!-- body -->
 ## 前提条件
@@ -186,14 +194,33 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま
 
 ## SCTPのサポート
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。
+ベータ版の機能として、これはデフォルトで有効化されます。
+クラスターレベルでSCTPを無効化するために、クラスター管理者はAPIサーバーで`--feature-gates=SCTPSupport=false,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を無効にする必要があります。
 
 {{< note >}}
 SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。
 {{< /note >}}
 
+## ネットワークポリシーでできないこと(少なくともまだ)
+
+Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存在しません。
+しかし、オペレーティングシステムのコンポーネント(SELinux、OpenVSwitch、IPTablesなど)、レイヤ7の技術(Ingressコントローラー、サービスメッシュ実装)、もしくはアドミッションコントローラーを使用して回避策を実装できる場合があります。
+Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下ののユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。
+
+- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。
+- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。
+- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。
+- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。
+- サードパーティによって実行される「ポリシー要求」の作成または管理
+- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー(これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します)。
+- 高度なポリシークエリと到達可能性ツール
+- 単一のポリシー宣言でポートの範囲を指定する機能
+- ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能
+- ポリシーを明示的に拒否する機能(現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します)。
+- ループバックまたは内向きのホストトラフィックを拒否する機能(Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません)。
+
 ## {{% heading "whatsnext" %}}
 
 - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。

content/ja/docs/concepts/services-networking/service.md

@@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
 
 ## Serviceを利用する動機
 
-{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。
+Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。
 {{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。
 
 各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。
@@ -35,7 +35,8 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ
 ## Serviceリソース {#service-resource}
 
 Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。
-ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。
+ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}}によって定義されます。
+その他の方法について知りたい場合は[セレクターなしのService](#services-without-selectors)を参照してください。
 
 例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。&mdash; フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。
 
@@ -90,11 +91,11 @@ ServiceのデフォルトプロトコルはTCPです。また、他の[サポー
 Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。
 例えば:
 
-  * プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
+* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
-  * Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合
+* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合
-  * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
+* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
 
-このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。
+このような場合において、ユーザーはPodセレクター*なしで*Serviceを定義できます。
 
 ```yaml
 apiVersion: v1
@@ -137,20 +138,19 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設
 ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。
 
 ### エンドポイントスライス
+
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。
 
-エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
+エンドポイントスライスは、[エンドポイントスライスのドキュメント](/ja/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。
 
 ### アプリケーションプロトコル
 
-{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。
-
-アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。
 
+`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。
+この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。
 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
 
 Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
@@ -162,9 +162,9 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。
 
 Serviceにおいてプロキシーを使う理由はいくつかあります。
 
- * DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
+* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
- * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
+* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
- * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
+* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
 
 ### user-spaceプロキシーモード {#proxy-mode-userspace}
 
@@ -211,12 +211,12 @@ IPVSプロキシーモードはiptablesモードと同様に、netfilterのフ
 
 IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。
 
-- `rr`: ラウンドロビン
+* `rr`: ラウンドロビン
-- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
+* `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
-- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
+* `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
-- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
+* `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
-- `sed`: 見込み遅延が最小なもの
+* `sed`: 見込み遅延が最小なもの
-- `nq`: キューなしスケジューリング
+* `nq`: キューなしスケジューリング
 
 {{< note >}}
 IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。
@@ -282,7 +282,7 @@ PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに
 これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
 [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は、下記のような環境変数を生成します。
+例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。
 
 ```shell
 REDIS_MASTER_SERVICE_HOST=10.0.0.11
@@ -308,12 +308,12 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ
 CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。
 もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。
 
-例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。
+例えば、Kubernetesの`my-ns`というNamespace内で`my-service`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`my-service.my-ns`というDNSレコードを作成します。
-`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。
+`my-ns`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`my-service.my-ns`でも動作します)。
 
 他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。
 
-Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
+Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`my-service.my-ns`というServiceが`http`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`http`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
 
 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。
 [DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
@@ -337,8 +337,8 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一
 ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。
 しかしDNSのシステムは下記の2つ両方を探索し、設定します。
 
-  * [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
+* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
-  * 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
+* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード
 
 ## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types}
 
@@ -349,16 +349,15 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類
 
 `Type`項目の値と、そのふるまいは以下のようになります。
 
-   * `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
+* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
-   * [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
+* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。
-   * [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
+* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
-   * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
+* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
+  {{< note >}}
+  `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
+  {{< /note >}}
 
-     {{< note >}}
+また、Serviceを公開するために[Ingress](/ja/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
-     `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。
-     {{< /note >}}
-
-また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。
 Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。
 
 ### NodePort タイプ {#nodeport}
@@ -461,6 +460,7 @@ Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部
 タブを選択してください。
 {{% /tab %}}
 {{% tab name="GCP" %}}
+
 ```yaml
 [...]
 metadata:
@@ -469,8 +469,10 @@ metadata:
         cloud.google.com/load-balancer-type: "Internal"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="AWS" %}}
+
 ```yaml
 [...]
 metadata:
@@ -479,8 +481,10 @@ metadata:
         service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Azure" %}}
+
 ```yaml
 [...]
 metadata:
@@ -489,8 +493,10 @@ metadata:
         service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="IBM Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -502,6 +508,7 @@ metadata:
 
 {{% /tab %}}
 {{% tab name="OpenStack" %}}
+
 ```yaml
 [...]
 metadata:
@@ -510,8 +517,10 @@ metadata:
         service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Baidu Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -520,8 +529,10 @@ metadata:
         service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
 [...]
 ```
+
 {{% /tab %}}
 {{% tab name="Tencent Cloud" %}}
+
 ```yaml
 [...]
 metadata:
@@ -529,6 +540,7 @@ metadata:
     service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
 [...]
 ```
+
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -675,8 +687,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく
         # この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。
         # デフォルトでは5 この値は2から60の間で設定可能
 
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
+        # ELBが作成される際に追加されるセキュリティグループのリスト
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groupsアノテーションと異なり
+        # 元々ELBに付与されていたセキュリティグループを置き換えることになります。
+
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
         # ELBに追加される予定のセキュリティーグループのリスト
+
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
+        # ロードバランサーがターゲットノードを指定する際に利用するキーバリューのペアのコンマ区切りリストです。
 ```
 
 #### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support}
@@ -738,8 +758,9 @@ spec:
       annotations:
         # 指定したノードでロードバランサーをバインドします
         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: ""
@@ -750,11 +771,14 @@ spec:
         # ロードバランサーのタイプを指定します
         # 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer)
         service.kubernetes.io/loadbalance-type: xxxxx
+
         # パブリックネットワーク帯域幅の課金方法を指定します
         # 有効な値: 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)。
         service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"
+
         # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します
         # そうでない場合、すべてのノードが登録されます
         service.kubernetes.io/local-svc-only-bind-node-with-pod: true
@@ -777,6 +801,7 @@ spec:
   type: ExternalName
   externalName: my.database.example.com
 ```
+
 {{< note >}}
 ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。
 IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。
@@ -857,7 +882,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ
 ### ServiceのIPアドレス {#ips-and-vips}
 
 実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。
-その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
+その代わり、kube-proxyは必要な時に透過的にリダイレクトされる*仮想*IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。
 クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。
 Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。
 
@@ -914,12 +939,12 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
 
 {{< note >}}
-ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
+ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
 {{< /note >}}
 
 ### PROXY プロトコル
 
-もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
+もしクラウドプロバイダーがサポートしている場合、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
 
 ロードバランサーは、最初の一連のオクテットを送信します。
 下記のような例となります。
@@ -927,15 +952,16 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで
 ```
 PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 ```
+
 クライアントからのデータのあとに追加されます。
 
 ### SCTP
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
+KubernetesはService、Endpoints、EndpointSlice、NetworkPolicyとPodの定義において`protocol`フィールドの値でSCTPをサポートしています。ベータ版の機能のため、この機能はデフォルトで有効になっています。SCTPをクラスターレベルで無効にするには、クラスター管理者はAPI Serverにおいて`SCTPSupport` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を`--feature-gates=SCTPSupport=false,…`と設定して無効にする必要があります。
 
-そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。
+そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、EndpointSlice、NetworkPolicy、またはPodの`protocol`フィールドに`SCTP`を設定できます。
 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
 
 #### 警告 {#caveat-sctp-overview}
@@ -967,11 +993,8 @@ SCTPはWindowsベースのNodeではサポートされていません。
 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
 {{< /warning >}}
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
+* [Connecting Applications with Services](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
-* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
+* [Ingress](/ja/docs/concepts/services-networking/ingress/)を参照してください。
-* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
+* [EndpointSlices](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。
-* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。

content/ja/docs/concepts/storage/dynamic-provisioning.md

@@ -54,7 +54,7 @@ parameters:
 
 ユーザーは`PersistentVolumeClaim`リソース内でStorageClassを含むことで、動的にプロビジョンされたStorageをリクエストできます。Kubernetes v1.6以前では、この機能は`volume.beta.kubernetes.io/storage-class`アノテーションを介して使うことができました。しかしこのアノテーションではv1.6から廃止になりました。その代わりユーザーは現在では`PersistentVolumeClaim`オブジェクトの`storageClassName`を使う必要があります。このフィールドの値は、管理者によって設定された`StorageClass`の名前と一致しなければなりません([下記](#enabling-dynamic-provisioning)のセクションも参照ください)。
 
-"fast"というStorageClassを選択するために、例としてユーザーは下記の`PersistentVolumeClaim`を作成します。
+"fast"というStorageClassを選択するために、例としてユーザーは下記のPersistentVolumeClaimを作成します。
 
 ```yaml
 apiVersion: v1

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

@@ -162,6 +162,49 @@ spec:
 ```
 ただし、カスタムリサイクラーPodテンプレートの`volumes`パート内で指定された特定のパスは、リサイクルされるボリュームの特定のパスに置き換えられます。
 
+### 永続ボリュームの予約
+
+コントロールプレーンは、永続ボリュームクレームをクラスター内の一致する永続ボリュームに[バインド](#バインディング)できます。
+ただし、永続ボリュームクレームを特定の永続ボリュームにバインドする場合、それらを事前にバインドする必要があります。
+
+永続ボリュームクレームで永続ボリュームを指定することにより、その特定の永続ボリュームと永続ボリュームクレームの間のバインディングを宣言します。
+永続ボリュームが存在し、その`claimRef`フィールドで永続ボリュームクレームを予約していない場合に永続ボリュームと永続ボリュームクレームがバインドされます。
+
+バインディングは、ノードアフィニティを含むいくつかのボリュームの一致基準に関係なく発生します。
+コントロールプレーンは、依然として[ストレージクラス](/docs/concepts/storage/storage-classes/)、アクセスモード、および要求されたストレージサイズが有効であることをチェックします。
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: foo-pvc
+  namespace: foo
+spec:
+  storageClassName: "" # 空の文字列を明示的に指定する必要があります。そうしないとデフォルトのストレージクラスが設定されてしまいます。
+  volumeName: foo-pv
+  ...
+```
+
+この方法は、永続ボリュームへのバインド特権を保証するものではありません。
+他の永続ボリュームクレームが指定した永続ボリュームを使用できる場合、最初にそのストレージボリュームを予約する必要があります。
+永続ボリュームの`claimRef`フィールドに関連する永続ボリュームクレームを指定して、他の永続ボリュームクレームがその永続ボリュームにバインドできないようにしてください。
+
+
+```yaml
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: foo-pv
+spec:
+  storageClassName: ""
+  claimRef:
+    name: foo-pvc
+    namespace: foo
+  ...
+```
+
+これは、既存の永続ボリュームを再利用する場合など、`claimPolicy`が`Retain`に設定されている永続ボリュームを使用する場合に役立ちます。
+
 ### 永続ボリュームクレームの拡大
 
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}
@@ -247,26 +290,32 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー
 
 PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。
 
-* GCEPersistentDisk
+* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
-* AWSElasticBlockStore
+* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
-* AzureFile
+* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File
-* AzureDisk
+* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
-* CSI
+* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
-* FC (Fibre Channel)
+  (**非推奨**)
-* FlexVolume
+* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
-* Flocker
+* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
-* NFS
+* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
-* iSCSI
+* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
-* RBD (Ceph Block Device)
+* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
-* CephFS
+* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
-* Cinder (OpenStack block storage)
+* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume
-* Glusterfs
+  (テスト用の単一ノードのみ。マルチノードクラスターでは動作しません。代わりに`local`ボリュームを利用することを検討してください。)
-* VsphereVolume
+* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage
-* Quobyte Volumes
+* [`local`](/docs/concepts/storage/volumes/#local) - ノードにマウントされたローカルストレージデバイス
-* HostPath (テスト用の単一ノードのみ。ローカルストレージはどのような方法でもサポートされておらず、またマルチノードクラスターでは動作しません)
+* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage
-* Portworx Volumes
+* `photonPersistentDisk` - Photon controller persistent disk
-* ScaleIO Volumes
+  (対応するクラウドプロバイダーが削除されたため、このボリュームタイプは機能しなくなりました。)
-* StorageOS
+* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume
+* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
+* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
+* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume
+  (**非推奨**)
+* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume
+* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
 
 ## 永続ボリューム
 

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

@@ -1,5 +1,37 @@
 ---
 title: "ワークロード"
 weight: 50
+description: >
+  Kubernetesにおけるデプロイ可能な最小のオブジェクトであるPodと、高レベルな抽象化がPodの実行を助けることを理解します。
+no_list: true
 ---
 
+{{< glossary_definition term_id="workload" length="short" >}}
+ワークロードが1つのコンポーネントからなる場合でも、複数のコンポーネントが協調して動作する場合でも、Kubernetesではそれらは[Pod](/ja/docs/concepts/workloads/pods)の集合として実行されます。Kubernetesでは、Podはクラスター上で実行中の{{< glossary_tooltip text="コンテナ" term_id="container" >}}の集合として表されます。
+
+Podには定義されたライフサイクルがあります。たとえば、一度Podがクラスター上で実行中になると、そのPodが実行中の{{< glossary_tooltip text="ノード" term_id="node" >}}上で深刻な障害が起こったとき、そのノード上のすべてのPodは停止してしまうことになります。Kubernetesではそのようなレベルの障害を最終的なものとして扱うため、たとえノードが後で復元したとしても、ユーザーは新しいPodを作成し直す必要があります。
+
+しかし、生活をかなり楽にするためには、それぞれのPodを直接管理する必要はありません。_ワークロードリソース_ を利用すれば、あなたの代わりにPodの集合の管理を行ってもらえます。これらのリソースはあなたが指定した状態に一致するように{{< glossary_tooltip term_id="controller" text="コントローラー" >}}を設定し、正しい種類のPodが正しい数だけ実行中になることを保証してくれます。
+
+ワークロードリソースには、次のような種類があります。
+
+* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)(レガシーなリソース{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}を置き換えるものです)
+* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
+* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)(ストレージドライバやネットワークプラグインなど、ノードローカルな機能を提供するためのPodを実行するために使われます)
+* [Job](/docs/concepts/workloads/controllers/job/)と[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)(実行後に完了するようなタスクのために使われます)
+
+多少関連のある2種類の補助的な概念もあります。
+* [ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)は、オブジェクトが _所有するリソース_ が削除された後に、そのオブジェクトをクラスターからクリーンアップします。
+* [終了したリソースのためのTTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)は、Jobの完了後、定義した時間が経過した後にJobを削除します。
+
+## {{% heading "whatsnext" %}}
+
+各リソースについて読む以外にも、以下のページでそれぞれのワークロードに関連する特定のタスクについて学ぶことができます。
+
+* [Deploymentを使用してステートレスアプリケーションを実行する](/ja/docs/tasks/run-application/run-stateless-application-deployment/)
+* [単一レプリカ](/ja/docs/tasks/run-application/run-single-instance-stateful-application/)または[レプリカセット](/ja/docs/tasks/run-application/run-replicated-stateful-application/)のいずれかとしてステートフルなアプリケーションを実行する
+* [CronJobを使用して自動タスクを実行する](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+アプリケーションが実行できるようになったら、インターネット上で公開したくなるかもしれません。その場合には、[Service](/ja/docs/concepts/services-networking/service/)として公開したり、ウェブアプリケーションだけの場合、[Ingress](/ja/docs/concepts/services-networking/ingress)を使用することができます。
+
+コードを設定から分離するKubernetesのしくみについて学ぶには、[設定](/ja/docs/concepts/configuration/)を読んでください。

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

@@ -1,4 +1,4 @@
 ---
-title: "コントローラー"
+title: "ワークロードリソース"
 weight: 20
 ---

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

@@ -70,8 +70,6 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ
 
 もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
 
-また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{<glossary_tooltip term_id = "controller">}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。
-
 ### 選択したNode上でPodを稼働させる
 
 もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node

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

@@ -95,7 +95,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
   コマンドの実行結果は以下のとおりです。
   ```shell
   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-  deployment.apps/nginx-deployment successfully rolled out
+  deployment "nginx-deployment" successfully rolled out
   ```
 
 4. 数秒後、再度`kubectl get deployments`を実行してください。
@@ -194,7 +194,7 @@ Deploymentを更新するには以下のステップに従ってください。
     ```
     もしくは
     ```
-    deployment.apps/nginx-deployment successfully rolled out
+    deployment "nginx-deployment" successfully rolled out
     ```
 
 更新されたDeploymentのさらなる情報を取得するには、以下を確認してください。
@@ -788,7 +788,7 @@ 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
+deployment "nginx-deployment" successfully rolled out
 ```
 そして`kubectl rollout`の終了ステータスが0となります（成功です）:
 ```shell

content/ja/docs/concepts/workloads/controllers/garbage-collection.md

@@ -124,7 +124,7 @@ kubectl delete replicaset my-repset --cascade=false
 
 ### Deploymentsに関する追記事項
 
-Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの_propagationPolicy_ が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。  
+Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの*propagationPolicy*が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。  
 さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。
 
 ## 既知の問題について

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

@@ -197,7 +197,7 @@ ReplicaSetオブジェクトの名前は、有効な
 
 ### Pod テンプレート
 
-`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
+`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
 他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
 
 テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。
@@ -300,7 +300,7 @@ ReplicaSetは、Node上のいくつかのエージェント(例えば、Kubelet
 
 ### Job
 
-PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。
+PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/workloads/controllers/job/)を使用してください。
 
 ### DaemonSet
 

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

@@ -1,4 +1,160 @@
 ---
 title: "Pod"
+content_type: concept
 weight: 10
+no_list: true
+card:
+  name: concepts
+  weight: 60
 ---
+
+*Pod*は、Kubernetes内で作成・管理できるコンピューティングの最小のデプロイ可能なユニットです(Podという名前は、たとえばクジラの群れ(pod of whales)やえんどう豆のさや(pea pod)などの表現と同じような意味です)。
+
+*Pod*は、1つまたは複数の{{< glossary_tooltip text="コンテナ" term_id="container" >}}のグループであり、ストレージやネットワークの共有リソースを持ち、コンテナの実行方法に関する仕様を持っています。同じPodに含まれるリソースは、常に同じ場所で同時にスケジューリングされ、共有されたコンテキストの中で実行されます。Podはアプリケーションに特化した「論理的なホスト」をモデル化します。つまり、1つのPod内には、1つまたは複数の比較的密に結合されたアプリケーションコンテナが含まれます。クラウド外の文脈で説明すると、アプリケーションが同じ物理ホストや同じバーチャルマシンで実行されることが、クラウドアプリケーションの場合には同じ論理ホスト上で実行されることに相当します。
+
+アプリケーションコンテナと同様に、Podでも、Podのスタートアップ時に実行される[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を含めることができます。また、クラスターで利用できる場合には、[エフェメラルコンテナ](/ja/docs/concepts/workloads/pods/ephemeral-containers/)を注入してデバッグすることもできます。
+
+<!-- body -->
+
+## Podとは何か？
+
+{{< note >}}
+KubernetesはDockerだけでなく複数の{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}をサポートしていますが、[Docker](https://www.docker.com/)が最も一般的に知られたランタイムであるため、Docker由来の用語を使ってPodを説明するのが理解の助けとなります。
+{{< /note >}}
+
+Podの共有コンテキストは、Dockerコンテナを隔離するのに使われているのと同じ、Linuxのnamespaces、cgroups、場合によっては他の隔離技術の集合を用いて作られます。Podのコンテキスト内では、各アプリケーションが追加の準隔離技術を適用することもあります。
+
+Dockerの概念を使って説明すると、Podは共有の名前空間と共有ファイルシステムのボリュームを持つDockerコンテナのグループに似ています。
+
+## Podを使用する
+
+通常、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、自分でPodを直接作成する必要はありません。その代わりに、{{< glossary_tooltip text="Deployment"
+term_id="deployment" >}}や{{< glossary_tooltip text="Job" term_id="job" >}}などのワークロードリソースを使用してPodを作成します。もしPodが状態を保持する必要がある場合は、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}リソースを使用することを検討してください。
+
+Kubernetesクラスター内のPodは、主に次の2種類の方法で使われます。
+
+* **単一のコンテナを稼働させるPod**。「1Pod1コンテナ」構成のモデルは、Kubernetesでは最も一般的なユースケースです。このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができます。Kubernetesはコンテナを直接管理するのではなく、Podを管理します。
+* **協調して稼働させる必要がある複数のコンテナを稼働させるPod**。単一のPodは、密に結合してリソースを共有する必要があるような、同じ場所で稼働する複数のコンテナからなるアプリケーションをカプセル化することもできます。これらの同じ場所で稼働するコンテナ群は、単一のまとまりのあるサービスのユニットを構成します。たとえば、1つのコンテナが共有ボリュームからファイルをパブリックに配信し、別の*サイドカー*コンテナがそれらのファイルを更新するという構成が考えられます。Podはこれらの複数のコンテナ、ストレージリソース、一時的なネットワークIDなどを、単一のユニットとしてまとめます。
+
+  {{< note >}}
+  複数のコンテナを同じ場所で同時に管理するように単一のPod内にグループ化するのは、比較的高度なユースケースです。このパターンを使用するのは、コンテナが密に結合しているような特定のインスタンス内でのみにするべきです。
+  {{< /note >}}
+
+各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。Kubernetesでは、これは一般的に*レプリケーション*と呼ばれます。レプリケーションされたPodは、通常ワークロードリソースと、それに対応する{{< glossary_tooltip text="コントローラー" term_id="controller" >}}によって、作成・管理されます。
+
+Kubernetesがワークロードリソースとそのコントローラーを活用して、スケーラブルで自動回復するアプリケーションを実装する方法については、詳しくは[Podとコントローラー](#pods-and-controllers)を参照してください。
+
+### Podが複数のコンテナを管理する方法
+
+Podは、まとまりの強いサービスのユニットを構成する、複数の協調する(コンテナとして実行される)プロセスをサポートするために設計されました。単一のPod内の複数のコンテナは、クラスター内の同じ物理または仮想マシン上で、自動的に同じ場所に配置・スケジューリングされます。コンテナ間では、リソースや依存関係を共有したり、お互いに通信したり、停止するときにはタイミングや方法を協調して実行できます。
+
+たとえば、あるコンテナが共有ボリューム内のファイルを配信するウェブサーバーとして動作し、別の「サイドカー」コンテナがリモートのリソースからファイルをアップデートするような構成が考えられます。この構成を以下のダイアグラムに示します。
+
+{{< figure src="/images/docs/pod.svg" alt="Podのダイアグラムの例" width="50%" >}}
+
+Podによっては、{{< glossary_tooltip text="appコンテナ" term_id="app-container" >}}に加えて{{< glossary_tooltip text="initコンテナ" term_id="init-container" >}}を持っている場合があります。initコンテナはappコンテナが起動する前に実行・完了するコンテナです。
+
+Podは、Podを構成する複数のコンテナに対して、[ネットワーク](#pod-networking)と[ストレージ](#pod-storage)の2種類の共有リソースを提供します。
+
+## Podを利用する
+
+通常Kubernetesでは、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、個別のPodを直接作成することはめったにありません。その理由は、Podがある程度一時的で使い捨てできる存在として設計されているためです。Podが作成されると(あなたが直接作成した場合でも、{{< glossary_tooltip text="コントローラー" term_id="controller" >}}が間接的に作成した場合でも)、新しいPodはクラスター内の{{< glossary_tooltip term_id="node" >}}上で実行されるようにスケジューリングされます。Podは、実行が完了するか、Podオブジェクトが削除されるか、リソース不足によって*強制退去*されるか、ノードが停止するまで、そのノード上にとどまります。
+
+{{< note >}}
+Pod内のコンテナの再起動とPodの再起動を混同しないでください。Podはプロセスではなく、コンテナが実行するための環境です。Podは削除されるまでは残り続けます。
+{{< /note >}}
+
+Podオブジェクトのためのマニフェストを作成したときは、指定したPodの名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)であることを確認してください。
+
+### Podとコンテナコントローラー {#pods-and-controllers}
+
+ワークロードリソースは、複数のPodを作成・管理するために利用できます。リソースに対応するコントローラーが、複製やロールアウトを扱い、Podの障害時には自動回復を行います。たとえば、あるノードに障害が発生した場合、コントローラーはそのノードの動作が停止したことを検知し、代わりのPodを作成します。そして、スケジューラーが代わりのPodを健全なノード上に配置します。
+
+以下に、1つ以上のPodを管理するワークロードリソースの一例をあげます。
+
+* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
+* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
+* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
+
+### Podテンプレート
+
+{{< glossary_tooltip text="workload" term_id="workload" >}}リソース向けのコントローラーは、Podを*Podテンプレート*を元に作成し、あなたの代わりにPodを管理してくれます。
+
+PodTemplateはPodを作成するための仕様で、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)、[Job](/ja/docs/concepts/workloads/controllers/job/)、[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)などのワークロードリソースの中に含まれています。
+
+ワークロードリソースに対応する各コントローラーは、ワークロードオブジェクト内にある`PodTemplate`を使用して実際のPodを作成します。`PodTemplate`は、アプリを実行するために使われるワークロードリソースがどんな種類のものであれ、その目的の状態の一部を構成するものです。
+
+以下は、単純なJobのマニフェストの一例で、1つのコンテナを実行する`template`があります。Pod内のコンテナはメッセージを出力した後、一時停止します。
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: hello
+spec:
+  template:
+    # これがPodテンプレートです
+    spec:
+      containers:
+      - name: hello
+        image: busybox
+        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+      restartPolicy: OnFailure
+    # Podテンプレートはここまでです
+```
+
+Podテンプレートを修正するか新しいPodに切り替えたとしても、すでに存在するPodには直接の影響はありません。ワークロードリソース内のPodテンプレートを変更すると、そのリソースは更新されたテンプレートを使用して代わりとなるPodを作成する必要があります。
+
+たとえば、StatefulSetコントローラーは、各StatefulSetごとに、実行中のPodが現在のPodテンプレートに一致することを保証します。Podテンプレートを変更するためにStatefulSetを編集すると、StatefulSetは更新されたテンプレートを元にした新しいPodを作成するようになります。最終的に、すべての古いPodが新しいPodで置き換えられ、更新は完了します。
+
+各ワークロードリソースは、Podテンプレートへの変更を処理するための独自のルールを実装しています。特にStatefulSetについて更に詳しく知りたい場合は、StatefulSetの基本チュートリアル内の[アップデート戦略](/ja/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets)を読んでください。
+
+ノード上では、{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}はPodテンプレートに関する詳細について監視や管理を直接行うわけではありません。こうした詳細は抽象化されています。こうした抽象化や関心の分離のおかげでシステムのセマンティクスが単純化され、既存のコードを変更せずにクラスターの動作を容易に拡張できるようになっているのです。
+
+## リソースの共有と通信
+
+Podは、データの共有と構成するコンテナ間での通信を可能にします。
+
+### Pod内のストレージ {#pod-storage}
+
+Podでは、共有ストレージである{{< glossary_tooltip text="ボリューム" term_id="volume" >}}の集合を指定できます。Pod内のすべてのコンテナは共有ボリュームにアクセスできるため、それら複数のコンテナでデータを共有できるようになります。また、ボリュームを利用すれば、Pod内のコンテナの1つに再起動が必要になった場合にも、Pod内の永続化データを保持し続けられるようにできます。Kubernetesの共有ストレージの実装方法とPodで利用できるようにする方法に関するさらに詳しい情報は、[ストレージ](/ja/docs/concepts/storage/)を読んでください。
+
+### Podネットワーク
+
+各Podには、各アドレスファミリーごとにユニークなIPアドレスが割り当てられます。Pod内のすべてのコンテナは、IPアドレスとネットワークポートを含むネットワーク名前空間を共有します。Podの中では(かつその場合に**のみ**)、そのPod内のコンテナは`localhost`を使用して他のコンテナと通信できます。Podの内部にあるコンテナが*Podの外部にある*エンティティと通信する場合、(ポートなどの)共有ネットワークリソースの使い方をコンテナ間で調整しなければなりません。Pod内では、コンテナはIPアドレスとポートの空間を共有するため、`localhost`で他のコンテナにアクセスできます。また、Pod内のコンテナは、SystemVのセマフォやPOSIXの共有メモリなど、標準のプロセス間通信を使って他のコンテナと通信することもできます。異なるPod内のコンテナは異なるIPアドレスを持つため、[特別な設定](/docs/concepts/policy/pod-security-policy/)をしない限りIPCで通信することはできません。異なるPod上で実行中のコンテナ間でやり取りをしたい場合は、IPネットワークを使用して通信できます。
+
+Pod内のコンテナは、システムのhostnameがPodに設定した`name`と同一であると考えます。ネットワークについての詳しい情報は、[ネットワーク](/ja/docs/concepts/cluster-administration/networking/)で説明しています。
+
+## コンテナの特権モード
+
+Pod内のどんなコンテナも、`privileged`フラグをコンテナのspecの[security context](/docs/tasks/configure-pod-container/security-context/)に設定することで、特権モード(privileged mode)を有効にできます。これは、ネットワークスタックの操作やハードウェアデバイスへのアクセスなど、オペレーティングシステムの管理者の権限が必要なコンテナの場合に役に立ちます。特権コンテナ内のプロセスはコンテナ外のプロセスが利用できるのとほぼ同等の権限を取得します。
+
+{{< note >}}
+この設定を有効にするには、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}が特権コンテナの概念をサポートしていなければなりません。
+{{< /note >}}
+
+## static Pod
+
+*static Pod*は、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}には管理されない、特定のノード上でkubeletデーモンによって直接管理されるPodのことです。大部分のPodはコントロープレーン(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})によって管理されますが、static Podの場合はkubeletが各static Podを直接管理します(障害時には再起動します)。
+
+static Podは常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。static Podの主な用途は、セルフホストのコントロールプレーンを実行すること、言い換えると、kubeletを使用して個別の[コントロールプレーンコンポーネント](/ja/docs/concepts/overview/components/#control-plane-components)を管理することです。
+
+kubeletは自動的にKubernetes APIサーバー上に各static Podに対応する{{< glossary_tooltip text="ミラーPod" term_id="mirror-pod" >}}の作成を試みます。つまり、ノード上で実行中のPodはAPIサーバー上でも見えるようになるけれども、APIサーバー上から制御はできないということです。
+
+## {{% heading "whatsnext" %}}
+
+* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)について学ぶ。
+* [PodPreset](/ja/docs/concepts/workloads/pods/podpreset/)について学ぶ。
+* [RuntimeClass](/ja/docs/concepts/containers/runtime-class/)と、それを用いてPodごとに異なるコンテナランタイム設定する方法について学ぶ。
+* [Podトポロジー分布制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)について読む。
+* [PodDisruptionBudget](/ja/docs/concepts/workloads/pods/disruptions/)と、それを使用してクラスターの停止(disruption)中にアプリケーションの可用性を管理する方法について読む。
+* PodはKubernetes REST API内のトップレベルのリソースです。[Pod](/ja/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)オブジェクトの定義では、オブジェクトの詳細について記述されています。
+* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)では、2つ以上のコンテナを利用する場合の一般的なレイアウトについて説明しています。
+
+Kubernetesが共通のPod APIを他のリソース内(たとえば{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}や{{< glossary_tooltip text="Deployment" term_id="deployment" >}}など)にラッピングしている理由の文脈を理解するためには、Kubernetes以前から存在する以下のような既存技術について読むのが助けになります。
+
+  * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+  * [Borg](https://research.google.com/pubs/pub43438.html)
+  * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+  * [Omega](https://research.google/pubs/pub41684/)
+  * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/)

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

@@ -20,7 +20,7 @@ Initコンテナは下記の項目をのぞいて、通常のコンテナと全
 * Initコンテナは常に完了するまで稼働します。
 * 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。
 
-もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`がNeverの場合、再起動されません。
+もしあるPodの単一のInitコンテナが失敗した場合、Kubeletは成功するまで何度もそのInitコンテナを再起動します。しかし、もしそのPodの`restartPolicy`がNeverで、そのPodの起動時にInitコンテナが失敗した場合、KubernetesはそのPod全体を失敗として扱います。
 
 PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。
 Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。

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

@@ -8,7 +8,7 @@ weight: 30
 
 このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。
 
-Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。
+Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、回復させるためのアクションを決定します。
 
 Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。
 
@@ -43,13 +43,13 @@ Podの各フェーズの値と意味は厳重に守られています。ここ
 
 これらが`phase`の取りうる値です。
 
-値 | 概要
+値          | 概要
-:-----|:-----------
+:-----------|:-----------
-`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
+`Pending`   | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。
-`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
+`Running`   | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。
-`Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。
+`Succeeded` | Pod内のすべてのコンテナが正常に終了し、再起動されません。
-`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
+`Failed`    | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
-`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。
+`Unknown`   | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。
 
 Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。
 
@@ -69,7 +69,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]
 
 ### `Running` {#container-state-running}
 
-`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
+`Running`状態はコンテナが問題なく実行されていることを示します。`postStart`フックが構成されていた場合、それはすでに実行が完了しています。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。
 
 ### `Terminated` {#container-state-terminated}
 
@@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME]
 
 Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。
 
-`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
+`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。
 
 ## PodのCondition {#pod-conditions}
 
@@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム
 
 ## コンテナのProbe {#container-probes}
 
-[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります:
 
 * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
   コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。
@@ -209,7 +209,7 @@ Podが削除されたときにリクエストを来ないようにするため
 
 ### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe}
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。
 コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。
@@ -220,7 +220,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、
 
 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。
 
-通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
+通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。多くのコンテナランタイムは、コンテナイメージで定義されたSTOPSIGNAL値を尊重し、TERMの代わりにこれを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。
 
 フローの例は下のようになります。
 

content/ja/docs/contribute/_index.md

@@ -1,55 +1,76 @@
 ---
 content_type: concept
-title: Kubernetesのドキュメントに貢献する
+title: K8sのドキュメントに貢献する
 linktitle: 貢献
 main_menu: true
+no_list: true
 weight: 80
+card:
+  name: 貢献
+  weight: 10
+  title: K8sへの貢献を始める
 ---
 
 <!-- overview -->
 
-ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。
+*Kubernetesは初心者でも経験者でも、全てのコントリビューターからの改善を歓迎しています！*
-はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。
 
+{{< note >}}
+Kubernetesへの貢献について総合的に知りたい場合は、[contributor documentation](https://www.kubernetes.dev/docs/)を参照してください。
+{{< /note >}}
+
+このウェブサイトは[Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs)が管理しています。
+
+Kubernetesドキュメントコントリビューターは
+
+- 既存のコンテンツを改善します
+- 新しいコンテンツを作成します
+- ドキュメントを翻訳します
+- Kubernetesリリースサイクルの一部としてドキュメントを管理・公開します
 
 <!-- body -->
 
 ## はじめに
 
-どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、プルリクエスト(PR)を用いて変更に貢献することができます。
+どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、[`kubernetes/website` GitHub リポジトリ](https://github.com/kubernetes/website)に対するプルリクエスト(PR)を用いて変更に貢献することができます。
-一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。
+Kubernetesコミュニティで効果的に働くためには、[git](https://git-scm.com/)と[GitHub](https://lab.github.com/)を基本的に使いこなせる必要があります。
-役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
-
-Kubernetesのドキュメントは、GitHubのリポジトリーにあります。
-どなたからの貢献も歓迎しますが、Kubernetesコミュニティの効果的な運用のためには、gitとGitHubを基本的に使いこなせる必要があります。
 
 ドキュメンテーションに関わるには:
 
 1. CNCFの[Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)にサインしてください。
 2. [ドキュメンテーションのリポジトリー](https://github.com/kubernetes/website)と、ウェブサイトの[静的サイトジェネレーター](https://gohugo.io)に慣れ親しんでください。
-3. [コンテンツの改善](https://kubernetes.io/docs/contribute/start/#improve-existing-content)と[変更レビュー](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)の基本的なプロセスを理解していることを確認してください。
+3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。
 
-## 貢献するためのベストプラクティス
+一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。
+役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
 
-- 明快で意味のあるGitコミットメッセージを書いてください。
+## はじめての貢献
-- PRがマージされたときにissueを参照し、自動的にissueをクローズする _Github Special Keywords_ を必ず含めるようにしてください。
+- 貢献のための複数の方法について学ぶために[貢献の概要](/docs/contribute/new-content/overview/)を読んでください。
-- タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。
+- 良い開始地点を探すために[`kubernetes/website` issueリスト](https://github.com/kubernetes/website/issues/)を確認してください。
-- あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。
+- 既存のドキュメントに対して[GitHubを使ってプルリクエストをオープン](/docs/contribute/new-content/open-a-pr/#changes-using-github)し、GitHubへのissueの登録について学んでください。
-- 追加文献 :
+- 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/docs/contribute/review/reviewing-prs/)を受けてください。
-    - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
+- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。
-    - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
+- [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/docs/contribute/style/hugo-shortcodes/)について勉強してください。
-    - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
+
+## 次のステップ
+
+- リポジトリの[ローカルクローンでの作業](/docs/contribute/new-content/open-a-pr/#fork-the-repo)について学んでください。
+- [リリース機能](/docs/contribute/new-content/new-features/)について記載してください。
+- [SIG Docs](/docs/contribute/participate/)に参加し、[memberやreviewer](/docs/contribute/participate/roles-and-responsibilities/)になってください。
+- [国際化](/docs/contribute/localization/)を始めたり、支援したりしてください。
+
+## SIG Docsに参加する
+
+[SIG Docs](/docs/contribute/participate/)はKubernetesのドキュメントとウェブサイトを公開・管理するコントリビューターのグループです。SIG Docsに参加することはKubernetesコントリビューター（機能開発でもそれ以外でも）にとってKubernetesプロジェクトに大きな影響を与える素晴らしい方法の一つです。
+
+SIG Docsは複数の方法でコミュニケーションをとっています。
+
+- [Kubernetes Slackインスタンスの`#sig-docs`に参加してください](https://slack.k8s.io/)。自己紹介を忘れずに！
+- [`kubernetes-sig-docs`メーリングリストに参加してください](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)。ここでは幅広い議論が起こり、公式な決定が記録されます。
+- [毎週のSIG Docsビデオミーティング](https://github.com/kubernetes/community/tree/master/sig-docs)に参加してください。ミーティングは `#sig-docs`でアナウンスされ、[Kubernetesコミュニティミーティングカレンダー](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)に追加されます。[Zoomクライアント](https://zoom.us/download)をダウンロードするか、電話を使って通話する必要があります。
 
 ## その他の貢献方法
 
-- TwitterやStack Overflowといったオンラインフォーラムを通してKubernetesコミュニティに貢献したい方、または各地のミートアップやイベントについて知りたい方は[Kubernetes community site](/community/)へ。
+- [Kubernetesコミュニティサイト](/community/)を訪問してください。TwitterやStack Overflowに参加したり、Kubernetesの集会やイベントについて学んだりしてください。
-- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。
+- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)を読んでください。
-
+- [ブログ記事やケーススタディ](/docs/contribute/new-content/blogs-case-studies/)を投稿してください。
-
-## {{% heading "whatsnext" %}}
-
-- ドキュメントへの貢献の基本について、さらに知りたい場合は、[貢献の開始](/docs/contribute/start/)を参照してください。
-- 変更を提案をする際は、[Kubernetesドキュメンテーションスタイルガイド](/docs/contribute/style/style-guide/)に従ってください。
-- SIG Docsについて、さらに知りたい場合は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。
-- Kubernetesドキュメントのローカライズについて、さらに知りたい場合は、[Kubernetesドキュメントのローカライズ](/docs/contribute/localization/)を参照してください。
-

content/ja/docs/contribute/style/content-guide.md

@@ -31,7 +31,7 @@ Kubernetesのドキュメントにサードパーティーのコンテンツを
 - コンテンツがプロジェクト外のソフトウェアのドキュメントとなるが、Kubernetesを機能させるために必要である場合
 - コンテンツがkubernetes.ioの正規のコンテンツであるか、他の場所の正規のコンテンツへのリンクである場合
 
-### サードパーティーのコンテンツ
+### サードパーティーのコンテンツ {#third-party-content}
 
 Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes](https://github.com/kubernetes)および[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizationsに存在するプロジェクト)の適用例が含まれています。