Merge remote-tracking branch 'upstream/main' into dev-1.24

2022-01-24 09:07:23 -08:00 · 2022-01-24 09:07:23 -08:00 · 6fb319b29c
parent dd1f2f1155 f89e0ba1c9
commit 6fb319b29c
97 changed files with 414 additions and 325 deletions
--- a/24
+++ b/24
@ -28,14 +28,14 @@ module-init:

 all: build ## Build site with production settings and put deliverables in ./public

-build: module-check ## Build site with production settings and put deliverables in ./public
-	hugo --minify
+build: module-check ## Build site with non-production settings and put deliverables in ./public
+	hugo --minify --environment development

 build-preview: module-check ## Build site with drafts and future posts enabled
-	hugo --buildDrafts --buildFuture
+	hugo --buildDrafts --buildFuture --environment preview

 deploy-preview: ## Deploy preview site via netlify
-	hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL)
+	hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL)

 functions-build:
 	$(NETLIFY_FUNC) build functions-src
@ -43,13 +43,15 @@ functions-build:
 check-headers-file:
 	scripts/check-headers-file.sh

-production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
+production-build: module-check ## Build the production site and ensure that noindex headers aren't added
+	hugo --minify --environment production
+	HUGO_ENV=production $(MAKE) check-headers-file

-non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
-	hugo --enableGitInfo
+non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing
+	hugo --enableGitInfo --environment nonprod

 serve: module-check ## Boot the development server.
-	hugo server --buildFuture
+	hugo server --buildFuture --environment development

 docker-image:
 	@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
@ -70,10 +72,10 @@ container-image: ## Build a container image for the preview of the website
 		--build-arg HUGO_VERSION=$(HUGO_VERSION)

 container-build: module-check
-	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify"
+	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development"

 container-serve: module-check ## Boot the development server using container. Run `make container-image` before this.
-	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
+	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir

 test-examples:
 	scripts/test_examples.sh install
@ -88,7 +90,7 @@ docker-internal-linkcheck:
 	$(MAKE) container-internal-linkcheck

 container-internal-linkcheck: link-checker-image-pull
-	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
+	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test
 	$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest

 clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md
--- a/assets/scss/_custom.scss
+++ b/assets/scss/_custom.scss
@ -215,6 +215,10 @@ body.td-404 main .error-details {
  }
 }

+body > footer {
+  width: 100vw;
+}
+
 /* FOOTER */
 footer {
  background-color: #303030;
@ -222,8 +226,14 @@ footer {
  padding: 1rem !important;
  min-height: initial !important;

-  .footer__links {
-    width: 100%;
+  > div, > p {
+    max-width: 95%;
+    @media only screen and (min-width: 768px) {
+      max-width: calc(min(80rem,90vw)); // avoid spreading too wide
+    }
+  }
+
+  > .footer__links {
    margin: auto;
    padding-bottom: 1rem;

@ -233,6 +243,8 @@ footer {
    }

    @media only screen and (min-width: 768px) {
+      max-width: calc(min(60rem,90vw)); // avoid spreading too wide
+
      nav {
        display: flex;
        flex-direction: row;
--- a/content/en/docs/concepts/architecture/cloud-controller.md
+++ b/content/en/docs/concepts/architecture/cloud-controller.md
@ -78,7 +78,7 @@ when you declare a Service resource that requires them.

 ## Authorization

-This section breaks down the access that the cloud controller managers requires
+This section breaks down the access that the cloud controller manager requires
 on various API objects, in order to perform its operations.

 ### Node controller {#authorization-node-controller}
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@ -67,7 +67,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://

 ### Calico

-[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
+[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.

 ### Cilium

@ -79,9 +79,9 @@ addressing, and it can be used in combination with other CNI plugins.

 ### CNI-Genie from Huawei

-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).

-CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
+CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.

 ### cni-ipvlan-vpc-k8s
 [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
@ -104,6 +104,11 @@ network complexity required to deploy Kubernetes at scale within AWS.
 [Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
 Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.

+### Contiv-VPP
+
+[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
+Kubernetes, using the [fd.io](https://fd.io/) data plane.
+
 ### Contrail / Tungsten Fabric

 [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
@ -122,7 +127,7 @@ With this toolset DANM is able to provide multiple separated network interfaces,

 ### Flannel

-[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
+[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
 network that satisfies the Kubernetes requirements. Many
 people have reported success with Flannel and Kubernetes.

@ -188,7 +193,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).

 ### Weave Net from Weaveworks

-[Weave Net](https://www.weave.works/products/weave-net/) is a
+[Weave Net](https://www.weave.works/oss/net/) is a
 resilient and simple to use network for Kubernetes and its hosted applications.
 Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
 or stand-alone.  In either version, it doesn't require any configuration or extra code
--- a/content/en/docs/concepts/cluster-administration/system-logs.md
+++ b/content/en/docs/concepts/cluster-administration/system-logs.md
@ -182,7 +182,8 @@ There are two types of system components: those that run in a container and thos
 that do not run in a container. For example:

 * The Kubernetes scheduler and kube-proxy run in a container.
-* The kubelet and container runtime, for example Docker, do not run in containers.
+* The kubelet and {{<glossary_tooltip term_id="container-runtime" text="container runtime">}}
+  do not run in containers.

 On machines with systemd, the kubelet and container runtime write to journald.
 Otherwise, they write to `.log` files in the `/var/log` directory.
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@ -858,7 +858,7 @@ operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
 glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
 feature, the
 [Ceph CSI driver](https://github.com/ceph/ceph-csi)
-must be installed on the cluster and the `CSIMigration` and `CSIMigrationRBD`
+must be installed on the cluster and the `CSIMigration` and `csiMigrationRBD`
 [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
 must be enabled.

@ -1133,6 +1133,7 @@ spec:
    volumeMounts:
    - name: workdir1
      mountPath: /logs
+      # The variable expansion uses round brackets (not curly brackets).
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@ -88,7 +88,7 @@ different Kubernetes components.
 | `CSIMigrationOpenStack` | `true` | Beta | 1.18 | |
 | `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
 | `CSIMigrationPortworx` | `false` | Alpha | 1.23 | |
-| `CSIMigrationRBD` | `false` | Alpha | 1.23 | |
+| `csiMigrationRBD` | `false` | Alpha | 1.23 | |
 | `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 |
 | `CSIStorageCapacity` | `true` | Beta | 1.21 | |
 | `CSIVolumeHealth` | `false` | Alpha | 1.21 | |
@ -653,9 +653,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
  operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling
  back to in-tree GCE plugin if a node does not have PD CSI plugin installed and
  configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationRBD`: Enables shims and translation logic to route volume
+- `csiMigrationRBD`: Enables shims and translation logic to route volume
  operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
-  CSIMigration and CSIMigrationRBD feature flags enabled and Ceph CSI plugin
+  CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
  installed and configured in the cluster. This flag has been deprecated in
  favor of the
  `InTreePluginRBDUnregister` feature flag which prevents the registration of
@ -731,6 +731,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
  on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `DaemonSetUpdateSurge`: Enables the DaemonSet workloads to maintain
  availability during update per node.
+  See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
 - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
  [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
 - `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the
--- a/content/en/docs/reference/glossary/container-runtime.md
+++ b/content/en/docs/reference/glossary/container-runtime.md
@ -15,7 +15,7 @@ tags:

 <!--more-->

-Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}},
+Kubernetes supports container runtimes such as
 {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
-and any implementation of the [Kubernetes CRI (Container Runtime
+and any other implementation of the [Kubernetes CRI (Container Runtime
 Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
--- a/content/en/docs/reference/kubectl/conventions.md
+++ b/content/en/docs/reference/kubectl/conventions.md
@ -31,29 +31,6 @@ For `kubectl run` to satisfy infrastructure as code:

 You can use the `--dry-run=client` flag to preview the object that would be sent to your cluster, without really submitting it.

-{{< note >}}
-All `kubectl run` generators are deprecated. See the Kubernetes v1.17 documentation for a [list](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) of generators and how they were used.
-{{< /note >}}
-
-#### Generators
-You can generate the following resources with a kubectl command, `kubectl create --dry-run=client -o yaml`:
-
-* `clusterrole`: Create a ClusterRole.
-* `clusterrolebinding`: Create a ClusterRoleBinding for a particular ClusterRole.
-* `configmap`: Create a ConfigMap from a local file, directory or literal value.
-* `cronjob`: Create a CronJob with the specified name.
-* `deployment`: Create a Deployment with the specified name.
-* `job`: Create a Job with the specified name.
-* `namespace`: Create a Namespace with the specified name.
-* `poddisruptionbudget`: Create a PodDisruptionBudget with the specified name.
-* `priorityclass`: Create a PriorityClass with the specified name.
-* `quota`: Create a Quota with the specified name.
-* `role`: Create a Role with single rule.
-* `rolebinding`: Create a RoleBinding for a particular Role or ClusterRole.
-* `secret`: Create a Secret using specified subcommand.
-* `service`: Create a Service using specified subcommand.
-* `serviceaccount`: Create a ServiceAccount with the specified name.
-
 ### `kubectl apply`

 * You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).
--- a/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md
+++ b/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md
@ -15,7 +15,7 @@ This page provides an overview of best practices when it comes to enforcing

 ## Using the built-in Pod Security Admission Controller

-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}

 The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
 intends to replace the deprecated PodSecurityPolicies. 
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@ -15,12 +15,19 @@ what is involved and describes related tasks for setting up nodes.

 <!-- body -->

+Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
+conforms with the 
+{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
+
+See [CRI version support](#cri-versions) for more information.
+
 This page lists details for using several common container runtimes with
 Kubernetes, on Linux:

 - [containerd](#containerd)
 - [CRI-O](#cri-o)
- [Docker](#docker)
+- [Docker Engine](#docker)
+- [Mirantis Container Runtime](#mcr)

 {{< note >}}
 For other operating systems, look for documentation specific to your platform.
@ -94,10 +101,19 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
 Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
 if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.

+## CRI version support {#cri-versions}
+
+Your container runtime must support at least v1alpha2 of the container runtime interface.
+
+Kubernetes {{< skew currentVersion >}}  defaults to using v1 of the CRI API.
+If a container runtime does not support the v1 API, the kubelet falls back to
+using the (deprecated) v1alpha2 API instead.
+
 ## Container runtimes

 {{% thirdparty-content %}}

+
 ### containerd

 This section contains the necessary steps to use containerd as CRI runtime.
@ -394,44 +410,28 @@ Please also note the changed `conmon_cgroup`, which has to be set to the value
 cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
 in sync.

-### Docker
+### Docker Engine {#docker}

-1. On each of your nodes, install the Docker for your Linux distribution as per 
-[Install Docker Engine](https://docs.docker.com/engine/install/#server). 
-You can find the latest validated version of Docker in this 
-[dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
+Docker Engine is the container runtime that started it all. Formerly known just as Docker,
+this container runtime is available in various forms.
+[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
+for installing this runtime.

-2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
+Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
+and context, see the [Dockershim deprecation FAQ](/dockershim).

-   ```shell
-   sudo mkdir /etc/docker
-   cat <<EOF | sudo tee /etc/docker/daemon.json
-   {
-     "exec-opts": ["native.cgroupdriver=systemd"],
-     "log-driver": "json-file",
-     "log-opts": {
-       "max-size": "100m"
-     },
-     "storage-driver": "overlay2"
-   }
-   EOF
-   ```
+You can also find third-party adapters that let you use Docker Engine with Kubernetes
+through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
+(CRI).

-   {{< note >}}
-   `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, 
-   or RHEL or CentOS using version 3.10.0-514 and above.
-   {{< /note >}}
+The following CRI adaptors are designed to work with Docker Engine:

-3. Restart Docker and enable on boot:
+- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis

-   ```shell
-   sudo systemctl enable docker
-   sudo systemctl daemon-reload
-   sudo systemctl restart docker
-   ```
+### Mirantis Container Runtime {#mcr}

-{{< note >}}
-For more information refer to
-  - [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
-  - [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
-{{< /note >}}
+[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is a commercially
+available container runtime that was formerly known as Docker Enterprise Edition.
+
+You can use Mirantis Container Runtime with Kubernetes using the open source
+[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@ -167,14 +167,13 @@ option. Your cluster requirements may need a different configuration.
    {{< /caution >}}

 1.  Apply the CNI plugin of your choice:
-    [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
+    [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) 
    to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable.
-
-    In this example we are using Weave Net:
-
-    ```sh
-    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-    ```
+  
+  {{< note >}}
+  You must pick a network plugin that suits your use case and deploy it before you move on to next step.
+  If you don't do this, you will not be able to launch your cluster properly.
+  {{< /note >}}

 1.  Type the following and watch the pods of the control plane components get started:

--- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
@ -10,20 +10,19 @@ weight: 20

 This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.

-In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads.
-
-
+In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services.

 ## {{% heading "prerequisites" %}}

-
 You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:

 ### Install the GMSACredentialSpec CRD
+
 A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
 Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`

 ### Install webhooks to validate GMSA users
+
 Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level:

 1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec.
@ -36,23 +35,23 @@ Installing the above webhooks and associated objects require the steps below:

 1. Install a secret with the certificate from above.

-1. Create a deployment for the core webhook logic. 
+1. Create a deployment for the core webhook logic.

-1. Create the validating and mutating webhook configurations referring to the deployment. 
+1. Create the validating and mutating webhook configurations referring to the deployment.

 A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a ```--dry-run=server``` option to allow you to review the changes that would be made to your cluster.

 The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)

-
-
 <!-- steps -->

 ## Configure GMSAs and Windows nodes in Active Directory
+
 Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)

 ## Create GMSA credential spec resources
-With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). 
+
+With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).

 Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:

@ -60,14 +59,14 @@ Following are the steps for generating a GMSA credential spec YAML manually in J

 1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`

-1. Use `Get-CredentialSpec` to show the path of the JSON file. 
+1. Use `Get-CredentialSpec` to show the path of the JSON file.

-1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. 
+1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes.

 The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`:

 ```yaml
-apiVersion: windows.k8s.io/v1alpha1
+apiVersion: windows.k8s.io/v1
 kind: GMSACredentialSpec
 metadata:
  name: gmsa-WebApp1  #This is an arbitrary name but it will be used as a reference
@ -92,6 +91,7 @@ credspec:
 The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml`

 ## Configure cluster role to enable RBAC on specific GMSA credential specs
+
 A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml`

 ```yaml
@ -108,6 +108,7 @@ rules:
 ```

 ## Assign role to service accounts to use specific GMSA credspecs
+
 A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.

 ```yaml
@ -127,6 +128,7 @@ roleRef:
 ```

 ## Configure GMSA credential spec reference in Pod spec
+
 The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`:

 ```yaml
@ -197,55 +199,17 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl

 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.

-## Containerd 
+## Authenticating to network shares usinig hostname of FQDN

-On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564). 
+If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN, but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.

-There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected. 
-
-```PowerShell
-ping adserver.ad.local
-```
-and correctly resolves the hostname to an IPv4 address. The output is similar to:
-
-```
-Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
-Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
-Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
-Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
-Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
+```cmd
+reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
 ```

-However, when attempting to browse the directory using the hostname
-
-```PowerShell
-cd \\adserver.ad.local\test
-```
-
-you see an error that implies the target share doesn't exist:
-
-```
-cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
-At line:1 char:1
-+ cd \\adserver.ad.local\test
-+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-    + CategoryInfo          : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
-    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
-```
-
-but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example:
-
-```PowerShell
-cd \\192.168.111.18\test
-```
-
-After you change into a directory within the share, you see a prompt similar to:
-
-```
-Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
-```
-
-To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares.
+Running Pods will then need to be recreated to pick up the behavior changes.
+More information on how this registry key is used can be found [here](
+https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)

 ## Troubleshooting

@ -258,8 +222,10 @@ In the example below the Pod did not get the credspec correctly:
 ```PowerShell
 kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
 ```
+
 `nltest.exe /parentdomain` results in the following error:
-```
+
+```PowerShell
 Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```

@ -278,7 +244,8 @@ nltest.exe /query
 ```

 Results in the following output:
-```
+
+```PowerShell
 I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```

@ -289,7 +256,8 @@ nltest /sc_reset:domain.example
 ```

 If the command is successful you will see and output similar to this:
-```
+
+```PowerShell
 Flags: 30 HAS_IP  HAS_TIMESERV
 Trusted DC Name \\dc10.domain.example
 Trusted DC Connection Status Status = 0 0x0 NERR_Success
--- a/content/en/docs/tasks/configure-pod-container/security-context.md
+++ b/content/en/docs/tasks/configure-pod-container/security-context.md
@ -469,7 +469,7 @@ kubectl delete pod security-context-demo-4

 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
 * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
-* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
+* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 * [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
 * [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
 * [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
--- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
@ -40,7 +40,7 @@ You may want to set
 [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) 
 (default to 0) and 
 [`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge) 
-(a beta feature and defaults to 25%) as well.
+(a beta feature and defaults to 0) as well.

 ### Creating a DaemonSet with `RollingUpdate` update strategy

--- a/content/en/docs/tasks/network/customize-hosts-file-for-pods.md
+++ b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md
@ -117,10 +117,15 @@ with the additional entries specified at the bottom.

 ## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}

-The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
-`hosts` file for each container of the Pod to prevent Docker from
-[modifying](https://github.com/moby/moby/issues/17190) the file after the
-containers have already been started.
+The kubelet manages the
+`hosts` file for each container of the Pod to prevent the container runtime from
+modifying the file after the containers have already been started.
+Historically, Kubernetes always used Docker Engine as its container runtime, and Docker Engine would
+then modify the `/etc/hosts` file after each container had started.
+
+Current Kubernetes can use a variety of container runtimes; even so, the kubelet manages the
+hosts file within each container so that the outcome is as intended regardless of which
+container runtime you use.

 {{< caution >}}
 Avoid making manual changes to the hosts file inside a container.
--- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-fish.md
+++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-fish.md
@ -0,0 +1,15 @@
+---
+title: "fish auto-completion"
+description: "Optional configuration to enable fish shell auto-completion."
+headless: true
+---
+
+The kubectl completion script for Fish can be generated with the command `kubectl completion fish`. Sourcing the completion script in your shell enables kubectl autocompletion.
+
+To do so in all your shell sessions, add the following line to your `~/.config/fish/config.fish` file:
+
+```shell
+kubectl completion fish | source
+```
+
+After reloading your shell, kubectl autocompletion should be working.
--- a/content/en/docs/tasks/tools/install-kubectl-linux.md
+++ b/content/en/docs/tasks/tools/install-kubectl-linux.md
@ -178,10 +178,11 @@ kubectl version --client

 kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell, which can save you a lot of typing.

-Below are the procedures to set up autocompletion for Bash and Zsh.
+Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.

 {{< tabs name="kubectl_autocompletion" >}}
 {{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
+{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
 {{< /tabs >}}

@ -192,7 +193,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
 1. Download the latest release with the command:

   ```bash
-   curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
+   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
   ```

 1. Validate the binary (optional)
--- a/content/en/docs/tasks/tools/install-kubectl-macos.md
+++ b/content/en/docs/tasks/tools/install-kubectl-macos.md
@ -161,10 +161,11 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,

 kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell which can save you a lot of typing.

-Below are the procedures to set up autocompletion for Bash and Zsh.
+Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.

 {{< tabs name="kubectl_autocompletion" >}}
 {{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
+{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
 {{< /tabs >}}

--- a/content/it/_index.html
+++ b/content/it/_index.html
@ -41,12 +41,12 @@ Kubernetes è open source, e ti offre la libertà di spostare i tuoi carichi di
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">Guarda il Video</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Partecipa alla KubeCon ad Amsterdam (13-16 Agosto 2020)</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Partecipa alla KubeCon a Valencia, Spagna + Virtual (16-20 maggio 2022)</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Partecipa alla KubeCon a Boston (17-20 Novembre 2020)</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Partecipa al KubeCon a Detroit, Michigan (24-28 ottobre 2022)</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
--- a/content/ja/docs/concepts/architecture/cloud-controller.md
+++ b/content/ja/docs/concepts/architecture/cloud-controller.md
@ -177,7 +177,7 @@ rules:

 ## {{% heading "whatsnext" %}}

-[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+[Cloud Controller Manager Administration](/ja/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
 はクラウドコントラーマネージャーの実行と管理を説明しています。

 どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？
@ -186,4 +186,4 @@ rules:

 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。

-プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
+プラグイン開発ついての詳細な情報は、[Developing Cloud Controller Manager](/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を見てください。
--- a/content/ja/docs/concepts/architecture/master-node-communication.md
+++ b/content/ja/docs/concepts/architecture/master-node-communication.md
@ -17,7 +17,7 @@ weight: 20
 ## クラスターからマスターへの通信

 クラスターからマスターへのすべての通信経路は、APIサーバーで終端します(他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません)。
-一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
+一般的には、1つ以上の形式のクライアント[認証](/ja/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート(443)でリモート接続をlistenするように構成されています。
 特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。

 ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
--- a/content/ja/docs/concepts/architecture/nodes.md
+++ b/content/ja/docs/concepts/architecture/nodes.md
@ -267,7 +267,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}
 `TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、
 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
-詳細は、[ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/)を参照してください。
+詳細は、[ノードのトポロジー管理ポリシーを制御する](/ja/docs/tasks/administer-cluster/topology-manager/)を参照してください。

 ## {{% heading "whatsnext" %}}

--- a/content/ja/docs/concepts/cluster-administration/addons.md
+++ b/content/ja/docs/concepts/cluster-administration/addons.md
@ -30,7 +30,7 @@ content_type: concept
 * [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)で確認できます。
+* [Romana](https://romana.io)は、[NetworkPolicy API](/ja/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/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。

 ## サービスディスカバリ
--- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md
@ -31,7 +31,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る

 * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。

-* 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。
+* 共有クラスターにおける[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。

 ## クラスターをセキュアにする

--- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md
@ -157,7 +157,7 @@ deployment.apps/my-deployment created
 persistentvolumeclaim/my-pvc created
 ```

-`kubectl`についてさらに知りたい場合は、[kubectlの概要](/docs/reference/kubectl/overview/)を参照してください。
+`kubectl`についてさらに知りたい場合は、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。

 ## ラベルを有効に使う

@ -294,7 +294,7 @@ my-nginx-2035384211-u3t6x   1/1       Running   0          23m       fe

 このコマンドでは"app=nginx"というラベルのついた全てのPodを出力し、Podのtierという項目も表示します(`-L`または`--label-columns`で指定)。

-さらなる情報は、[ラベル](/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。
+さらなる情報は、[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)や[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)を参照してください。

 ## アノテーションの更新

@ -313,7 +313,7 @@ metadata:
 ...
 ```

-さらなる情報は、[アノテーション](/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。
+さらなる情報は、[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/) や、[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate)を参照してください。

 ## アプリケーションのスケール

@ -443,7 +443,7 @@ deployment.apps/my-nginx scaled
 kubectl edit deployment/my-nginx
 ```

-できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/docs/concepts/workloads/controllers/deployment/)を参照してください。
+できました!Deploymentはデプロイされたnginxのアプリケーションを宣言的にプログレッシブに更新します。更新途中では、決まった数の古いレプリカのみダウンし、一定数の新しいレプリカが希望するPod数以上作成されても良いことを保証します。詳細について学ぶには[Deployment page](/ja/docs/concepts/workloads/controllers/deployment/)を参照してください。



--- a/content/ja/docs/concepts/configuration/configmap.md
+++ b/content/ja/docs/concepts/configuration/configmap.md
@ -192,6 +192,6 @@ immutable: true

 ## {{% heading "whatsnext" %}}

-* [Secret](/docs/concepts/configuration/secret/)について読む。
+* [Secret](/ja/docs/concepts/configuration/secret/)について読む。
 * [Podを構成してConfigMapを使用する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を読む。
 * コードを設定から分離する動機を理解するために[The Twelve-Factor App](https://12factor.net/ja/)を読む。
--- a/content/ja/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md
@ -51,8 +51,8 @@ Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォル

 CPUとメモリーは、まとめて*コンピュートリソース*または単に*リソース*と呼ばれます。
 コンピューティングリソースは、要求され、割り当てられ、消費され得る測定可能な量です。
-それらは[API resources](/docs/concepts/overview/kubernetes-api/)とは異なります。
-Podや[Services](/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
+それらは[API resources](/ja/docs/concepts/overview/kubernetes-api/)とは異なります。
+Podや[Services](/ja/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。

 ## Podとコンテナのリソース要求と制限

@ -624,9 +624,9 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0

 ## {{% heading "whatsnext" %}}

-* [コンテナとPodへのメモリーリソースの割り当て](/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う
+* [コンテナとPodへのメモリーリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-memory-resource/)ハンズオンを行う

-* [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う
+* [コンテナとPodへのCPUリソースの割り当て](/ja/docs/tasks/configure-pod-container/assign-cpu-resource/)ハンズオンを行う

 * 要求と制限の違いの詳細については、[リソースQoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)を参照する

--- a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@ -14,7 +14,7 @@ kubeconfigを使用すると、クラスターに、ユーザー、名前空間

 デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。

-kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。
+kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。

 <!-- body -->

--- a/content/ja/docs/concepts/configuration/secret.md
+++ b/content/ja/docs/concepts/configuration/secret.md
@ -311,9 +311,9 @@ stringData:

 Secretを作成するには、いくつかのオプションがあります。

- [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/)
+- [create Secret using `kubectl` command](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [create Secret from config file](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [create Secret using kustomize](/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

 ## Secretの編集

@ -636,7 +636,7 @@ Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecrets
 - アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します
 - imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。

-この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
+この機能は、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、
 ```yaml
 apiVersion: v1
 kind: Secret
@ -662,7 +662,7 @@ kubeletはこの情報をPodのためにプライベートイメージをpullす

 #### imagePullSecretを手動で指定する

-`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。
+`ImagePullSecrets`の指定の方法は[コンテナイメージのドキュメント](/ja/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)に記載されています。

 ### imagePullSecretsが自動的にアタッチされるようにする

@ -1006,7 +1006,7 @@ HTTPリクエストを扱い、複雑なビジネスロジックを処理し、
 ### Secret APIを使用するクライアント

 Secret APIとやりとりするアプリケーションをデプロイするときには、[RBAC](
-/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
+/ja/docs/reference/access-authn-authz/rbac/)のような[認可ポリシー](
 /docs/reference/access-authn-authz/authorization/)を使用して、アクセスを制限すべきです。
 Secretは様々な種類の重要な値を保持することが多く、サービスアカウントのトークンのようにKubernetes内部や、外部のシステムで昇格できるものも多くあります。個々のアプリケーションが、Secretの能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。

--- a/content/ja/docs/concepts/containers/_index.md
+++ b/content/ja/docs/concepts/containers/_index.md
@ -19,7 +19,7 @@ no_list: true
 <!-- body -->

 ## コンテナイメージ {#container-images}
-[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。
+[コンテナイメージ](/ja/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。

 設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。

--- a/content/ja/docs/concepts/containers/container-environment.md
+++ b/content/ja/docs/concepts/containers/container-environment.md
@ -50,7 +50,7 @@ FOO_SERVICE_PORT=<サービスが実行されているポート>
 ## {{% heading "whatsnext" %}}


-* [コンテナライフサイクルフック](/docs/concepts/containers/container-lifecycle-hooks/)の詳細
-* [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン
+* [コンテナライフサイクルフック](/ja/docs/concepts/containers/container-lifecycle-hooks/)の詳細
+* [コンテナライフサイクルイベントへのハンドラー紐付け](/ja/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン


--- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@ -8,7 +8,7 @@ weight: 20

 アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。追加のAPIは、[service-catalog](/docs/concepts/extend-kubernetes/service-catalog/)のような既製のソリューション、または自分で開発したAPIのいずれかです。

-アグリゲーションレイヤーは、[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。
+アグリゲーションレイヤーは、[カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)とは異なり、{{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}に新しい種類のオブジェクトを認識させる方法です。



--- a/content/ja/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ja/docs/concepts/extend-kubernetes/operator.md
@ -26,8 +26,9 @@ Kubernetes上でワークロードを稼働させている人は、しばしば
 Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
 ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。

+
 Kubernetesの{{< glossary_tooltip text="オペレーターパターン" term_id="operator-pattern" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、一つ以上のカスタムリソースに{{< glossary_tooltip text="カスタムコントローラー" term_id="controller" >}}をリンクすることで、クラスターの振る舞いを拡張することを可能にします。
-オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
+オペレーターはKubernetes APIのクライアントで、[Custom Resource](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。

 ## オペレーターの例 {#example}

--- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md
@ -3,7 +3,7 @@ title: フィールドセレクター(Field Selectors)
 weight: 60
 ---

-_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。  
+_フィールドセレクター(Field Selectors)_ は、1つかそれ以上のリソースフィールドの値を元に[Kubernetesリソースを選択](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects)するためのものです。  
 フィールドセレクタークエリの例は以下の通りです。  

 * `metadata.name=my-service`
--- a/content/ja/docs/concepts/overview/working-with-objects/names.md
+++ b/content/ja/docs/concepts/overview/working-with-objects/names.md
@ -9,7 +9,7 @@ weight: 20

 クラスター内の各オブジェクトには、そのタイプのリソースに固有の[_名前_](#names)があります。すべてのKubernetesオブジェクトには、クラスター全体で一意の[_UID_](#uids)もあります。

-たとえば、同じ[名前空間](/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。
+たとえば、同じ[名前空間](/ja/docs/concepts/overview/working-with-objects/namespaces/)内に`myapp-1234`という名前のPodは1つしか含められませんが、`myapp-1234`という名前の1つのPodと1つのDeploymentを含めることができます。

 ユーザーが一意ではない属性を付与するために、Kubernetesは[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)と[アノテーション](/ja/docs/concepts/overview/working-with-objects/annotations/)を提供しています。

--- a/content/ja/docs/concepts/policy/limit-range.md
+++ b/content/ja/docs/concepts/policy/limit-range.md
@ -6,7 +6,7 @@ weight: 10

 <!-- overview -->

-デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。
+デフォルトでは、コンテナは、Kubernetesクラスター上の[計算リソース](/ja/docs/concepts/configuration/manage-resources-containers/)の消費を制限されずに実行されます。リソースクォータを利用すれば、クラスター管理者はリソースの消費と作成を{{< glossary_tooltip text="名前空間" term_id="namespace" >}}ベースで制限することができます。名前空間内では、Podやコンテナは名前空間のリソースクォータで定義された範囲内でできるだけ多くのCPUとメモリーを消費できてしまうため、1つのPodまたはコンテナが利用可能なすべてのリソースを専有してしまう恐れがあります。LimitRangeを利用すれば、このような名前空間内での(Podやコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。

 <!-- body -->

@ -50,7 +50,7 @@ LimitRangeに対する競合や変更は、すでに作成済みのリソース
 制限の使用例については、以下のページを読んでください。

 - [名前空間ごとにCPUの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。
- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
+- [名前空間ごとにメモリーの最小値と最大値の制約を設定する方法](/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
 - [名前空間ごとにCPUのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。
 - [名前空間ごとにメモリーのRequestとLimitのデフォルト値を設定する方法](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
 - [名前空間ごとにストレージ消費量の最小値と最大値を設定する方法](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。
--- a/content/ja/docs/concepts/policy/resource-quotas.md
+++ b/content/ja/docs/concepts/policy/resource-quotas.md
@ -44,7 +44,7 @@ ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/

 ## リソースクォータの計算

-特定の名前空間において、[コンピュートリソース](/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。
+特定の名前空間において、[コンピュートリソース](/ja/docs/concepts/configuration/manage-resources-containers/)の合計に上限を設定できます。

 下記のリソースタイプがサポートされています。

@ -152,7 +152,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ
 | `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 |
 | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 |
 | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 |
-| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |
+| `PriorityClass` | 指定された[優先度クラス](/ja/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 |

 `BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します:

@ -201,7 +201,7 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ

 {{< feature-state for_k8s_version="v1.17" state="stable" >}}

-Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。
+Podは特定の[優先度](/ja/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。

 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。

--- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md
@ -66,5 +66,5 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
 * [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/)
+  * [ストレージ容量の追跡](/ja//ja/docs/concepts/storage/storage-capacity/)
  * [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
--- a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@ -40,7 +40,7 @@ kubectl get pods -n kube-system | grep kube-scheduler

 スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。

-クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。
+クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/ja/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。

 [スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。

--- a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md
@ -191,7 +191,7 @@ Kubernetesはユーザーまたはコントローラーが明示的に指定し
 自動的に設定されるtolerationは、taintに対応する問題がNodeで検知されても5分間はそのNodeにPodが残されることを意味します。
 {{< /note >}}

-[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。
+[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のPodは次のtaintに対して`NoExecute`のtolerationが`tolerationSeconds`を指定せずに設定されます。

  * `node.kubernetes.io/unreachable`
  * `node.kubernetes.io/not-ready`
--- a/content/ja/docs/concepts/security/pod-security-standards.md
+++ b/content/ja/docs/concepts/security/pod-security-standards.md
@ -281,7 +281,7 @@ Gatekeeper](https://github.com/open-policy-agent/gatekeeper)があります。
 ### WindowsのPodにはどのプロファイルを適用すればよいですか?

 Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。
-特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
+特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
 したがって、現段階では標準化されたセキュリティポリシーは存在しません。

 ### サンドボックス化されたPodはどのように扱えばよいでしょうか?
--- a/content/ja/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ja/docs/concepts/services-networking/connect-applications-service.md
@ -62,7 +62,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
 つまり、同じcontainerPortを使用して同じノードで複数のnginx Podを実行し、IPを使用してクラスター内の他のPodやノードからそれらにアクセスできます。
 Dockerと同様に、ポートは引き続きホストノードのインターフェイスに公開できますが、ネットワークモデルにより、この必要性は根本的に減少します。

-興味があれば、これを[どのように達成するか](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。
+興味があれば、これを[どのように達成するか](/ja/docs/concepts/cluster-administration/networking/#how-to-achieve-this)について詳しく読むことができます。

 ## Serviceを作成する

@ -203,7 +203,7 @@ NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
 kube-dns   ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   8m
 ```

-このセクションの残りの部分は、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバーがあることを前提にしています。ここではCoreDNSクラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。
+このセクションの残りの部分は、寿命の長いIP(my-nginx)を持つServiceと、そのIPに名前を割り当てたDNSサーバーがあることを前提にしています。ここではCoreDNSクラスターアドオン(アプリケーション名: `kube-dns`)を使用しているため、標準的なメソッド(`gethostbyname()`など) を使用してクラスター内の任意のPodからServiceに通信できます。CoreDNSが起動していない場合、[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)または[Installing CoreDNS](/ja/docs/tasks/administer-cluster/coredns/#installing-coredns)を参照し、有効にする事ができます。curlアプリケーションを実行して、これをテストしてみましょう。

 ```shell
 kubectl run curl --image=radial/busyboxplus:curl -i --tty
@ -232,7 +232,7 @@ Address 1: 10.0.162.149

 * https用の自己署名証明書(既にID証明書を持っている場合を除く)
 * 証明書を使用するように構成されたnginxサーバー
-* Podが証明書にアクセスできるようにする[Secret](/docs/concepts/configuration/secret/)
+* Podが証明書にアクセスできるようにする[Secret](/ja/docs/concepts/configuration/secret/)

 これらはすべて[nginx httpsの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)から取得できます。
 これにはツールをインストールする必要があります。
--- a/content/ja/docs/concepts/services-networking/dual-stack.md
+++ b/content/ja/docs/concepts/services-networking/dual-stack.md
@ -98,4 +98,4 @@ IPv6が有効になった外部ロードバランサーをサポートしてい

 ## {{% heading "whatsnext" %}}

-* [IPv4/IPv6デュアルスタックのネットワークを検証する](/docs/tasks/network/validate-dual-stack)
+* [IPv4/IPv6デュアルスタックのネットワークを検証する](/ja/docs/tasks/network/validate-dual-stack)
--- a/content/ja/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md
@ -127,6 +127,6 @@ EndpointSliceを使用する実装では、エンドポイントを複数のス

 ## {{% heading "whatsnext" %}}

-* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
+* [EndpointSliceの有効化](/ja/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む

--- a/content/ja/docs/concepts/services-networking/service-topology.md
+++ b/content/ja/docs/concepts/services-networking/service-topology.md
@ -139,6 +139,6 @@ spec:

 ## {{% heading "whatsnext" %}}

-* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。
+* [Serviceトポトジーを有効にする](/ja/docs/tasks/administer-cluster/enabling-service-topology)を読む。
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。

--- a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md
@ -38,7 +38,7 @@ CronJobは、クラスターがアイドル状態になりそうなときにJob

 {{< codenew file="application/job/cronjob.yaml" >}}

-([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).
+([Running Automated Tasks with a CronJob](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/)ではこの例をより詳しく説明しています。).

 ## CronJobの制限 {#cron-job-limitations}

--- a/content/ja/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md
@ -105,7 +105,7 @@ nodeAffinity:

 ### TaintsとTolerations

-DaemonSetのPodは[TaintsとTolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。
+DaemonSetのPodは[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)の設定を尊重します。下記のTolerationsは、関連する機能によって自動的にDaemonSetのPodに追加されます。

 | Toleration Key                           | Effect     | Version | Description |
 | ---------------------------------------- | ---------- | ------- | ----------- |
@ -151,7 +151,7 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`

 ### 静的Pod Pods

-Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
+Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。

 ### Deployment

--- a/content/ja/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ja/docs/concepts/workloads/controllers/deployment.md
@ -562,7 +562,7 @@ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
 deployment.apps/nginx-deployment scaled
 ```

-クラスター内で[水平Podオートスケーラー](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。
+クラスター内で[水平Podオートスケーラー](/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)が有効になっていると仮定します。ここでDeploymentのオートスケーラーを設定し、稼働しているPodのCPU使用量に基づいて、稼働させたいPodのレプリカ数の最小値と最大値を設定できます。

 ```shell
 kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
--- a/content/ja/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md
@ -94,7 +94,7 @@ spec:

 * nginxという名前のHeadlessServiceは、ネットワークドメインをコントロールするために使われます。
 * webという名前のStatefulSetは、specで3つのnginxコンテナのレプリカを持ち、そのコンテナはそれぞれ別のPodで稼働するように設定されています。
-* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。
+* volumeClaimTemplatesは、PersistentVolumeプロビジョナーによってプロビジョンされた[PersistentVolume](/ja/docs/concepts/storage/persistent-volumes/)を使って安定したストレージを提供します。

 StatefulSetの名前は有効な[名前](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。

@ -159,7 +159,7 @@ StatefulSet {{< glossary_tooltip text="コントローラー" term_id="controlle

 StatefulSetは`pod.Spec.TerminationGracePeriodSeconds`を0に指定すべきではありません。これは不安全で、やらないことを強く推奨します。さらなる説明としては、[StatefulSetのPodの強制削除](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。

-上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。
+上記の例のnginxが作成されたとき、3つのPodは`web-0`、`web-1`、`web-2`の順番でデプロイされます。`web-1`は`web-0`が[RunningかつReady状態](/ja/docs/concepts/workloads/pods/pod-lifecycle/)になるまでは決してデプロイされないのと、同様に`web-2`は`web-1`がRunningかつReady状態にならないとデプロイされません。もし`web-0`が`web-1`がRunningかつReady状態になった後だが、`web-2`が起動する前に失敗した場合、`web-2`は`web-0`の再起動が成功し、RunningかつReady状態にならないと再起動されません。

 もしユーザーが`replicas=1`といったようにStatefulSetにパッチをあてることにより、デプロイされたものをスケールすることになった場合、`web-2`は最初に停止されます。`web-1`は`web-2`が完全にシャットダウンされ削除されるまでは、停止されません。もし`web-0`が、`web-2`が完全に停止され削除された後だが、`web-1`の停止の前に失敗した場合、`web-1`は`web-0`がRunningかつReady状態になるまでは停止されません。

@ -205,6 +205,6 @@ Kubernetes1.7とそれ以降のバージョンにおいて、StatefulSetの`.spe
 ## {{% heading "whatsnext" %}}


-* [ステートフルなアプリケーションのデプロイ](/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
-* [StatefulSetを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
+* [ステートフルなアプリケーションのデプロイ](/ja/docs/tutorials/stateful-application/basic-stateful-set/)の例を参考にしてください。
+* [StatefulSetを使ったCassandraのデプロイ](/ja/docs/tutorials/stateful-application/cassandra/)の例を参考にしてください。
 * [レプリカを持つステートフルアプリケーションを実行する](/ja/docs/tasks/run-application/run-replicated-stateful-application/)の例を参考にしてください。
--- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
@ -89,7 +89,7 @@ PodにはPodStatusがあります。それはPodが成功したかどうかの

 * `PodScheduled`: PodがNodeにスケジュールされました。
 * `ContainersReady`: Pod内のすべてのコンテナが準備できた状態です。
-* `Initialized`: すべての[Initコンテナ](/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
+* `Initialized`: すべての[Initコンテナ](/ja/docs/concepts/workloads/pods/init-containers)が正常に実行されました。
 * `Ready`: Podはリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。

 フィールド名         | 内容
--- a/content/ja/docs/contribute/_index.md
+++ b/content/ja/docs/contribute/_index.md
@ -39,17 +39,17 @@ Kubernetesコミュニティで効果的に働くためには、[git](https://gi

 1. CNCFの[Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)にサインしてください。
 2. [ドキュメンテーションのリポジトリー](https://github.com/kubernetes/website)と、ウェブサイトの[静的サイトジェネレーター](https://gohugo.io)に慣れ親しんでください。
-3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。
+3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/ja/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。

 一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。
 役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。

 ## はじめての貢献
- 貢献のための複数の方法について学ぶために[貢献の概要](/docs/contribute/new-content/overview/)を読んでください。
+- 貢献のための複数の方法について学ぶために[貢献の概要](/ja/docs/contribute/new-content/overview/)を読んでください。
 - 良い開始地点を探すために[`kubernetes/website` issueリスト](https://github.com/kubernetes/website/issues/)を確認してください。
 - 既存のドキュメントに対して[GitHubを使ってプルリクエストをオープン](/docs/contribute/new-content/open-a-pr/#changes-using-github)し、GitHubへのissueの登録について学んでください。
 - 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/docs/contribute/review/reviewing-prs/)を受けてください。
- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。
+- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/ja/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。
 - [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/docs/contribute/style/hugo-shortcodes/)について勉強してください。

 ## 次のステップ
@ -57,7 +57,7 @@ Kubernetesコミュニティで効果的に働くためには、[git](https://gi
 - リポジトリの[ローカルクローンでの作業](/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/)を始めたり、支援したりしてください。
+- [国際化](/ja/docs/contribute/localization/)を始めたり、支援したりしてください。

 ## SIG Docsに参加する

--- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md
@ -330,7 +330,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
 `APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
 - `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
+- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/ja/docs/tutorials/clusters/apparmor/)で確認できます。
 - `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
 - `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
 - `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
@ -379,7 +379,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `EndpointSlice`: よりスケーラブルで拡張可能なネットワークエンドポイントのエンドポイントスライスを有効にします。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/)をご覧ください。
 - `EndpointSliceProxying`: このフィーチャーゲートを有効にすると、kube-proxyはエンドポイントの代わりにエンドポイントスライスをプライマリデータソースとして使用し、スケーラビリティとパフォーマンスの向上を実現します。[Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).をご覧ください。
 - `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
- `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
+- `HugePages`: 事前に割り当てられた[huge pages](/ja/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
 - `HugePageStorageMediumSize`: 事前に割り当てられた複数のサイズの[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)のサポートを有効にします。
 - `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
 - `HPAScaleToZero`: カスタムメトリクスまたは外部メトリクスを使用するときに、`HorizontalPodAutoscaler`リソースの`minReplicas`を0に設定できるようにします。
@ -400,7 +400,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/)機能を有効にします。
 - `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
 - `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
+- `PodShareProcessNamespace`: Podで実行されているコンテナ間で単一のプロセス名前空間を共有するには、Podで`shareProcessNamespace`の設定を有効にします。詳細については、[Pod内のコンテナ間でプロセス名前空間を共有する](/ja/docs/tasks/configure-pod-container/share-process-namespace/)をご覧ください。
 - `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
 - `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
 - `QOSReserved`: QoSレベルでのリソース予約を許可して、低いQoSレベルのポッドが高いQoSレベルで要求されたリソースにバーストするのを防ぎます（現時点ではメモリのみ）。
@ -409,7 +409,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
 - `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
 - `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/docs/concepts/containers/runtime-class/)機能を有効にします。
+- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/ja/docs/concepts/containers/runtime-class/)機能を有効にします。
 - `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
 - `SCTPSupport`: `Service`、`Endpoints`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
 - `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
@ -429,7 +429,7 @@ GAになってからさらなる変更を加えることは現実的ではない
 - `TaintNodesByCondition`: [ノードの条件](/ja/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動Taintを有効にします。
 - `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
 - `TokenRequestProjection`: [Projectedボリューム](/docs/concepts/storage/volumes/#projected)を使用したPodへのサービスアカウントのトークンの注入を有効にします。
- `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
+- `TTLAfterFinished`: [TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
 - `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
 - `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
 - `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
--- a/content/ja/docs/reference/glossary/container.md
+++ b/content/ja/docs/reference/glossary/container.md
@ -2,7 +2,7 @@
 title: コンテナ
 id: container
 date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /ja/docs/concepts/overview/what-is-kubernetes/#why-containers
 short_description: >
  軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。

--- a/content/ja/docs/reference/glossary/controller.md
+++ b/content/ja/docs/reference/glossary/controller.md
@ -2,7 +2,7 @@
 title: Controller
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /ja/docs/concepts/architecture/controller/
 short_description: >
  クラスターの状態をAPIサーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。

--- a/content/ja/docs/reference/glossary/kube-apiserver.md
+++ b/content/ja/docs/reference/glossary/kube-apiserver.md
@ -2,7 +2,7 @@
 title: APIサーバー
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/concepts/overview/components/#kube-apiserver
+full_link: /ja/docs/concepts/overview/components/#kube-apiserver
 short_description: >
  Kubernetes APIを提供するコントロールプレーンのコンポーネントです。

--- a/content/ja/docs/reference/glossary/namespace.md
+++ b/content/ja/docs/reference/glossary/namespace.md
@ -2,7 +2,7 @@
 title: Namespace
 id: namespace
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /ja/docs/concepts/overview/working-with-objects/namespaces
 short_description: >
  同一の物理クラスター上で複数の仮想クラスターをサポートするために使われる抽象概念です。

--- a/content/ja/docs/reference/kubectl/cheatsheet.md
+++ b/content/ja/docs/reference/kubectl/cheatsheet.md
@ -347,7 +347,7 @@ kubectl api-resources --api-group=extensions # "extensions" APIグループの
 `-o=custom-columns=<spec>` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します
 `-o=custom-columns-file=<filename>` | `<filename>`ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します
 `-o=json`     | JSON形式のAPIオブジェクトを出力します
-`-o=jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
+`-o=jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
 `-o=jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath)式で定義されたフィールドを出力します
 `-o=name`     | リソース名のみを出力し、それ以外は何も出力しません。
 `-o=wide`     | 追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。
--- a/content/ja/docs/reference/kubectl/overview.md
+++ b/content/ja/docs/reference/kubectl/overview.md
@ -8,7 +8,7 @@ card:
 ---

 <!-- overview -->
-`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
+`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
 この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。


--- a/content/ja/docs/reference/tools.md
+++ b/content/ja/docs/reference/tools.md
@ -8,7 +8,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組

 <!-- body -->
 ## Kubectl
-[`kubectl`](/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。
+[`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。

 ## Kubeadm
 [`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。
@ -17,7 +17,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組
 [`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。

 ## Dashboard
-[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。
+[`Dashboard`](/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)は、KubernetesのWebベースのユーザインタフェースで、コンテナ化されたアプリケーションをKubernetesクラスタにデプロイしたり、トラブルシューティングしたり、クラスタとそのリソース自体を管理したりすることが出来ます。

 ## Helm
 [`Kubernetes Helm`](https://github.com/helm/helm)は、事前に設定されたKubernetesリソースのパッケージ、別名Kubernetes chartsを管理するためのツールです。
--- a/content/ja/docs/setup/production-environment/tools/kops.md
+++ b/content/ja/docs/setup/production-environment/tools/kops.md
@ -220,7 +220,7 @@ for production clusters!

 ### 他のアドオンの参照

-See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
+See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.

 ## クリーンアップ

--- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@ -162,7 +162,7 @@ To start using your cluster, you need to run the following as a regular user:

 You should now deploy a Pod network to the cluster.
 Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
-  /docs/concepts/cluster-administration/addons/
+  /ja/docs/concepts/cluster-administration/addons/

 You can now join any number of machines by running the following on each node
 as root:
@ -395,8 +395,8 @@ kubectl delete node <node name>
 * <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
 * `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
 * Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
-* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
-* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
+* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)で確認する。
+* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/ja/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。

 ### フィードバック {#feedback}
--- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@ -29,7 +29,7 @@ when using kubeadm to set up a kubernetes cluster.
 * Three hosts that can talk to each other over ports 2379 and 2380. This
  document assumes these default ports. However, they are configurable through
  the kubeadm config file.
-* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+* Each host must [have docker, kubelet, and kubeadm installed](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
 * Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
  can satisfy this requirement.
--- a/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@ -147,7 +147,7 @@ Calico、Canal、FlannelのCNIプロバイダは、HostPortをサポートして

 ## サービスIP経由でPodにアクセスすることができない

- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。
+- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/ja/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。

 - VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。

--- a/content/ja/docs/setup/production-environment/tools/kubespray.md
+++ b/content/ja/docs/setup/production-environment/tools/kubespray.md
@ -22,7 +22,7 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
 * continuous integration tests

 To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/ja/docs/setup/production-environment/tools/kops/).



--- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md
@ -241,4 +241,4 @@ spec:
    app: iis-2019
 ```

-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
+[RuntimeClass]: https://kubernetes.io/ja/docs/concepts/containers/runtime-class/
--- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@ -290,7 +290,7 @@ contexts:
  name: exp-scratch
 ```

-kubeconfigファイルに関するさらなる情報を参照するには、[kubeconfigファイルを使ってクラスターへのアクセスを管理する](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を参照してください。
+kubeconfigファイルに関するさらなる情報を参照するには、[kubeconfigファイルを使ってクラスターへのアクセスを管理する](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を参照してください。

 ## $HOME/.kubeディレクトリの内容を確認する

--- a/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/ja/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@ -143,7 +143,7 @@ service/frontend created

 {{< note >}}
 nginxの構成は、[コンテナイメージ](/examples/service/access/Dockerfile)に焼き付けられます。
-これを行うためのより良い方法は、[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
+これを行うためのより良い方法は、[ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)を使用して、構成をより簡単に変更できるようにすることです。
 {{< /note >}}

 ## フロントエンドServiceと対話
--- a/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/ja/docs/tasks/access-application-cluster/service-access-application-cluster.md
@ -140,6 +140,6 @@ Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet


 詳細は
-[serviceを利用してアプリケーションと接続する](/docs/concepts/services-networking/connect-applications-service/)
+[serviceを利用してアプリケーションと接続する](/ja/docs/concepts/services-networking/connect-applications-service/)
 を確認してください。

--- a/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
+++ b/content/ja/docs/tasks/administer-cluster/enabling-endpointslices.md
@ -38,5 +38,5 @@ EndpoitSliceはベータ版の機能です。APIとEndpointSlice{{< glossary_too
 ## {{% heading "whatsnext" %}}


-* [EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)を参照してください。
+* [EndpointSlice](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。
--- a/content/ja/docs/tasks/administer-cluster/extended-resource-node.md
+++ b/content/ja/docs/tasks/administer-cluster/extended-resource-node.md
@ -85,7 +85,7 @@ Capacity:
 example.com/dongle:  4
 ```

-これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。
+これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/)を読んでください。

 ## 議論

--- a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@ -178,4 +178,4 @@ flannel Podが実行されると、ノードは`Ready`状態になり、ワー
 ## {{% heading "whatsnext" %}}


- [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
+- [Windows kubeadmノードのアップグレード](/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
--- a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
+++ b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
@ -9,7 +9,7 @@ weight: 40

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

-このページでは、[kubeadmで作られた](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
+このページでは、[kubeadmで作られた](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。



--- a/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+++ b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
@ -255,4 +255,4 @@ kubectl delete namespace constraints-mem-example

 * [コンテナとPodへのCPUリソースの割り当て](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [PodのQoS(サービス品質)を設定](/docs/tasks/configure-pod-container/quality-service-pod/)
+* [PodのQoS(サービス品質)を設定](/ja/docs/tasks/configure-pod-container/quality-service-pod/)
--- a/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
+++ b/content/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
@ -111,5 +111,5 @@ weight: 120

 ## {{% heading "whatsnext" %}}

-[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。
+[Node Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)についてさらに学ぶ。

--- a/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/ja/docs/tasks/debug-application-cluster/debug-stateful-set.md
@ -28,7 +28,7 @@ kubectl get pods -l app=myapp
 ```

 Podが長期間`Unknown`または`Terminating`の状態になっていることがわかった場合は、それらを処理する方法について[StatefulSetの削除](/ja/docs/tasks/run-application/delete-stateful-set/)タスクを参照してください。
-[Podのデバッグ](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。
+[Podのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)ガイドを使用して、StatefulSet内の個々のPodをデバッグできます。



--- a/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/ja/docs/tasks/inject-data-application/define-environment-variable-container.md
@ -108,7 +108,7 @@ spec:

 ## {{% heading "whatsnext" %}}

-* [環境変数](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
+* [環境変数](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)の詳細
 * [Secretを環境変数として使用する](/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)詳細
 * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)をご覧ください。

--- a/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/content/ja/docs/tasks/manage-gpus/scheduling-gpus.md
@ -111,7 +111,7 @@ Googleは、GKE上でNVIDIAのGPUを使用するための[手順](https://cloud.

 ## 異なる種類のGPUを搭載するクラスター

-クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。
+クラスター上の別のノードに異なる種類のGPUが搭載されている場合、[NodeラベルとNodeセレクター](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)を使用することで、Podを適切なノードにスケジューリングできます。

 以下に例を示します。

--- a/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md
@ -74,5 +74,5 @@ StatefulSet Podの強制削除は、常に慎重に、関連するリスクを
 ## {{% heading "whatsnext" %}}


-[StatefulSetのデバッグ](/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細
+[StatefulSetのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-stateful-set/)の詳細

--- a/content/ja/docs/tutorials/_index.md
+++ b/content/ja/docs/tutorials/_index.md
@ -24,19 +24,19 @@ content_type: concept

 ## 設定

-* [ConfigMapを用いたRedisの設定](/docs/tutorials/configuration/configure-redis-using-configmap/)
+* [ConfigMapを用いたRedisの設定](/ja/docs/tutorials/configuration/configure-redis-using-configmap/)

 ## ステートレスアプリケーション

 * [クラスター内のアプリケーションにアクセスするために外部IPアドレスを公開する](/ja/docs/tutorials/stateless-application/expose-external-ip-address/)

-* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/docs/tutorials/stateless-application/guestbook/)
+* [例: Redisを使用したPHPゲストブックアプリケーションのデプロイ](/ja/docs/tutorials/stateless-application/guestbook/)

 ## ステートフルアプリケーション

 * [StatefulSetの基本](/docs/tutorials/stateful-application/basic-stateful-set/)

-* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
+* [例: 永続ボリュームを使ったWordPressとMySQLのデプロイ](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)

 * [例: Stateful Setsを使ったCassandraのデプロイ](/docs/tutorials/stateful-application/cassandra/)

@ -50,7 +50,7 @@ content_type: concept

 ## サービス

-* [Source IPを使う](/docs/tutorials/services/source-ip/)
+* [Source IPを使う](/ja/docs/tutorials/services/source-ip/)



--- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@ -30,7 +30,7 @@ weight: 10

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

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

 			<p>各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスターの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecで<code>type</code>を指定することで、Serviceをさまざまな方法で公開することができます。</p>
 			<ul>
--- a/content/pl/_index.html
+++ b/content/pl/_index.html
@ -44,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Weź udział w KubeCon North America 11-15.10.2021</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Weź udział w KubeCon Europe 17-20.06.2022</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Weź udział w wirtualnym KubeCon Europe 17-20.5.2022</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Weź udział w KubeCon North America 24-28.10.2022</a>

 </div>
 <div id="videoPlayer">
--- a/content/pt-br/community/_index.html
+++ b/content/pt-br/community/_index.html
@ -8,7 +8,7 @@ cid: community
    <main>
        <div class="content">
            <h3>Garantir que o Kubernetes funcione bem em todos os lugares e para todos.</h3>
-            <p>Conecte-se à comunidade do Kubernetes no nosso canal <a href="http://slack.k8s.io/">canal do Slack</a>, <a href="https://discuss.kubernetes.io/"> no fórum de discussão</a>, ou participe do grupo <a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. 
+            <p>Conecte-se à comunidade do Kubernetes no nosso canal <a href="http://slack.k8s.io/">canal do Slack</a>, <a href="https://discuss.kubernetes.io/"> no fórum de discussão</a>, ou participe do grupo <a href="https://groups.google.com/a/kubernetes.io/g/dev/">dev@kubernetes Google group</a>. 
                Uma reunião semanal da comunidade é realizada por meio de videoconferência para discutir o estado das coisas. Veja essas 
 		<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">instruções </a> para obter informações sobre como participar.</p>
            <p>Você também pode participar do Kubernetes em todo o mundo através de nossa
--- a/content/ru/_index.html
+++ b/content/ru/_index.html
@ -41,7 +41,7 @@ Kubernetes — это проект с открытым исходным кодо
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">Смотреть видео</button>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Посетите KubeCon в Европе, 16-20 мая 2022 года</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Посетите KubeCon в Европе, 17-20 мая 2022 года</a>
        <br>
        <br>
        <br>
--- a/content/zh/docs/concepts/services-networking/_index.md
+++ b/content/zh/docs/concepts/services-networking/_index.md
@ -4,16 +4,95 @@ weight: 60
 description: Kubernetes 网络背后的概念和资源。
 ---

+<!--
+## The Kubernetes network model
+
+Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address.
+This means you do not need to explicitly create links between `Pods` and you
+almost never need to deal with mapping container ports to host ports.  
+This creates a clean, backwards-compatible model where `Pods` can be treated
+much like VMs or physical hosts from the perspectives of port allocation,
+naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration,
+and migration.
+
+Kubernetes imposes the following fundamental requirements on any networking
+implementation (barring any intentional network segmentation policies):
+
+* pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT
+* agents on a node (e.g. system daemons, kubelet) can communicate with all
+  pods on that node
+
+Note: For those platforms that support `Pods` running in the host network (e.g.
+Linux):
+
+* pods in the host network of a node can communicate with all pods on all
+  nodes without NAT
+-->
+## Kubernetes 网络模型   {#the-kubernetes-network-model}
+
+每一个 [`Pod`](/zh/docs/concepts/workloads/pods/) 都有它自己的IP地址，
+这就意味着你不需要显式地在 `Pod` 之间创建链接， 你几乎不需要处理容器端口到主机端口之间的映射。
+这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、
+[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)、应用配置和迁移的角度来看，
+`Pod` 可以被视作虚拟机或者物理主机。
+
+Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）：
+
+* [节点](/zh/docs/concepts/architecture/nodes/)上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
+* 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信
+
+备注：对于支持在主机网络中运行 `Pod` 的平台（比如：Linux）：
+
+* 运行在节点主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信
+
+<!--
+This model is not only less complex overall, but it is principally compatible
+with the desire for Kubernetes to enable low-friction porting of apps from VMs
+to containers.  If your job previously ran in a VM, your VM had an IP and could
+talk to other VMs in your project.  This is the same basic model.
+
+Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
+share their network namespaces - including their IP address and MAC address.
+This means that containers within a `Pod` can all reach each other's ports on
+`localhost`. This also means that containers within a `Pod` must coordinate port
+usage, but this is no different from processes in a VM.  This is called the
+"IP-per-pod" model.
+-->
+这个模型不仅不复杂，而且还和 Kubernetes 的实现从虚拟机向容器平滑迁移的初衷相符，
+如果你的任务开始是在虚拟机中运行的，你的虚拟机有一个 IP，
+可以和项目中其他虚拟机通信。这里的模型是基本相同的。
+
+Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。
+这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达对方端口。
+这也意味着 `Pod` 内的容器需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同，
+这也被称为“一个 Pod 一个 IP”模型。
+
+<!--
+How this is implemented is a detail of the particular container runtime in use.
+
+It is possible to request ports on the `Node` itself which forward to your `Pod`
+(called host ports), but this is a very niche operation. How that forwarding is
+implemented is also a detail of the container runtime. The `Pod` itself is
+blind to the existence or non-existence of host ports.
+-->
+如何实现以上需求是所使用的特定容器运行时的细节。
+
+也可以在 `Node` 本身请求端口，并用这类端口转发到你的 `Pod`（称之为主机端口），
+但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。
+`Pod` 自己并不知道这些主机端口的存在。
+
 <!--
 Kubernetes networking addresses four concerns:
- Containers within a Pod use networking to communicate via loopback.
+- Containers within a Pod [use networking to communicate](/docs/concepts/services-networking/dns-pod-service/) via loopback.
 - Cluster networking provides communication between different Pods.
- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
- You can also use Services to publish services only for consumption inside your cluster.
+- The [Service resource](/docs/concepts/services-networking/service/) lets you [expose an application running in Pods](/docs/concepts/services-networking/connect-applications-service/) to be reachable from outside your cluster.
+- You can also use Services to [publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/).
 -->

 Kubernetes 网络解决四方面的问题：
- 一个 Pod 中的容器之间通过本地回路（loopback）通信。
+- 一个 Pod 中的容器之间[通过本地回路（loopback）通信](/zh/docs/concepts/services-networking/dns-pod-service/)。
 - 集群网络在不同 pod 之间提供通信。
- Service 资源允许你对外暴露 Pods 中运行的应用程序，以支持来自于集群外部的访问。
- 可以使用 Services 来发布仅供集群内部使用的服务。
+- [Service 资源](/zh/docs/concepts/services-networking/service/)允许你
+  [对外暴露 Pods 中运行的应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)，
+  以支持来自于集群外部的访问。
+- 可以使用 Services 来[发布仅供集群内部使用的服务](/zh/docs/concepts/services-networking/service-traffic-policy/)。
--- a/content/zh/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md
@ -80,7 +80,7 @@ are used to expand queries. To learn more about DNS queries, see
 [the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)
 -->
 DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。kubelet 会为每个 Pod
-生成此文件。例如，对 `data` 的查询可能被展开为 `data.test.cluster.local`。
+生成此文件。例如，对 `data` 的查询可能被展开为 `data.test.svc.cluster.local`。
 `search` 选项的取值会被用来展开查询。要进一步了解 DNS 查询，可参阅
 [`resolv.conf` 手册页面](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)。

@ -384,13 +384,13 @@ following pod-specific DNS policies. These policies are specified in the

 - "`Default`": The Pod inherits the name resolution configuration from the node
  that the pods run on.
-  See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
+  See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
  for more details.
 - "`ClusterFirst`": Any DNS query that does not match the configured cluster
  domain suffix, such as "`www.kubernetes.io`", is forwarded to the upstream
  nameserver inherited from the node. Cluster administrators may have extra
  stub-domain and upstream DNS servers configured.
-  See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
+  See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
  for details on how DNS queries are handled in those cases.
 - "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
  explicitly set its DNS policy "`ClusterFirstWithHostNet`".
@ -405,11 +405,11 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod
 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置：

 - "`Default`": Pod 从运行所在的节点继承名称解析配置。参考
-  [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
+  [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
  获取更多信息。
 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"）
  都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
-  参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
+  参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
  了解在这些场景中如何处理 DNS 查询的信息。
 - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略
  "`ClusterFirstWithHostNet`"。
--- a/content/zh/docs/concepts/services-networking/service.md
+++ b/content/zh/docs/concepts/services-networking/service.md
@ -330,7 +330,7 @@ the endpoints controller has truncated the number of endpoints to 1000.
 <!--
 ### EndpointSlices
 -->
-### EndpointSlice
+### EndpointSlices

 {{< feature-state for_k8s_version="v1.21" state="stable" >}}

@ -345,12 +345,12 @@ endpoints.
 Endpoint Slices provide additional attributes and functionality which is
 described in detail in [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/).
 -->
-Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
-尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
-默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，
-届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。
+EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更可扩展的替代方案。
+尽管从概念上讲与 Endpoints 非常相似，但 EndpointSlices 允许跨多个资源分布网络端点。
+默认情况下，一旦到达 100 个 Endpoint，该 EndpointSlice 将被视为“已满”，
+届时将创建其他 EndpointSlices 来存储任何其他 Endpoints。

-Endpoint 切片提供了附加的属性和功能，这些属性和功能在
+EndpointSlices 提供了附加的属性和功能，这些属性和功能在
 [EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
 中有详细描述。

--- a/content/zh/docs/tasks/configure-pod-container/security-context.md
+++ b/content/zh/docs/tasks/configure-pod-container/security-context.md
@ -754,7 +754,7 @@ kubectl delete pod security-context-demo-4
 <!--
 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)
 * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
-* [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning)
+* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 * [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
 * [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
 * [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
@ -763,7 +763,7 @@ kubectl delete pod security-context-demo-4
 -->
 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) API 定义
 * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) API 定义
-* [使用最新的安全性增强来调优 Docker](https://opensource.com/business/15/3/docker-security-tuning)
+* [使用最新的安全性增强来调优 Docker](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 * [安全性上下文的设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
 * [属主管理的设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
 * [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)
--- a/content/zh/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
+++ b/content/zh/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
@ -62,29 +62,22 @@ Reload your shell and verify that bash-completion is correctly installed by typi
 -->
 ### 启动 kubectl 自动补全功能 {#enable-kubectl-autocompletion}

+#### Bash
+
 <!-- 
 You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
 -->
 你现在需要确保一点：kubectl 补全脚本已经导入（sourced）到 shell 会话中。
-这里有两种验证方法：
+可以通过以下两种方法进行设置：

-<!-- 
- Source the completion script in your `~/.bashrc` file:
-->
- 在文件 `~/.bashrc` 中导入（source）补全脚本：
-
-  ```bash
-  echo 'source <(kubectl completion bash)' >>~/.bashrc
-  ```
-
-<!-- 
- Add the completion script to the `/etc/bash_completion.d` directory:
-->
- 将补全脚本添加到目录 `/etc/bash_completion.d` 中：
-
-  ```bash
-  kubectl completion bash >/etc/bash_completion.d/kubectl
-  ```
+{{< tabs name="kubectl_bash_autocompletion" >}}
+{{{< tab name="当前用户" codelang="bash" >}}
+echo 'source <(kubectl completion bash)' >>~/.bashrc
+{{< /tab >}}
+{{< tab name="系统全局" codelang="bash" >}}
+kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
+{{< /tab >}}}
+{{< /tabs >}}

 <!-- 
 If you have an alias for kubectl, you can extend shell completion to work with that alias:
--- a/content/zh/docs/tasks/tools/included/optional-kubectl-configs-fish.md
+++ b/content/zh/docs/tasks/tools/included/optional-kubectl-configs-fish.md
@ -0,0 +1,31 @@
+---
+title: "fish 自动补全"
+description: "启用 fish 自动补全的可选配置。"
+headless: true
+---
+<!--
+---
+title: "fish auto-completion"
+description: "Optional configuration to enable fish shell auto-completion."
+headless: true
+---
+-->
+
+<!--
+The kubectl completion script for Fish can be generated with the command `kubectl completion fish`. Sourcing the completion script in your shell enables kubectl autocompletion.
+
+To do so in all your shell sessions, add the following line to your `~/.config/fish/config.fish` file:
+-->
+kubectl 通过命令 `kubectl completion fish` 生成 Fish 自动补全脚本。
+在 shell 中导入（Sourcing）该自动补全脚本，将启动 kubectl 自动补全功能。
+
+为了在所有的 shell 会话中实现此功能，请将下面内容加入到文件 `~/.config/fish/config.fish` 中。
+
+```shell
+kubectl completion fish | source
+```
+
+<!--
+After reloading your shell, kubectl autocompletion should be working.
+-->
+重新加载 shell 后，kubectl 自动补全功能将立即生效。
--- a/content/zh/docs/tasks/tools/install-kubectl-linux.md
+++ b/content/zh/docs/tasks/tools/install-kubectl-linux.md
@ -280,14 +280,15 @@ kubectl version --client
 <!-- 
 kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell, which can save you a lot of typing.

-Below are the procedures to set up autocompletion for Bash and Zsh.
+Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
 -->
 kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以为你节省大量的输入。

-下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。
+下面是为 Bash、Fish 和 Zsh 设置自动补全功能的操作步骤。

 {{< tabs name="kubectl_autocompletion" >}}
 {{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
+{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
 {{< /tabs >}}

--- a/content/zh/docs/tasks/tools/install-kubectl-macos.md
+++ b/content/zh/docs/tasks/tools/install-kubectl-macos.md
@ -268,14 +268,15 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
 <!-- 
 kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell which can save you a lot of typing.

-Below are the procedures to set up autocompletion for Bash and Zsh.
+Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
 -->
 kubectl 为 Bash、Zsh、Fish 和 PowerShell 提供自动补全功能，可以为你节省大量的输入。

-下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。
+下面是为 Bash、Fish 和 Zsh 设置自动补全功能的操作步骤。

 {{< tabs name="kubectl_autocompletion" >}}
 {{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
+{{< tab name="Fish" include="included/optional-kubectl-configs-fish.md" />}}
 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
 {{< /tabs >}}

--- a/layouts/_default/baseof.html
+++ b/layouts/_default/baseof.html
@ -1,6 +1,9 @@
 <!doctype html>
 <html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js">
-  <head>
+{{- if eq hugo.Environment "preview" -}}
+  <!-- deploy preview -->
+{{- end -}}
+  <head {{- if hugo.IsProduction -}}class="live-site"{{- end -}}>
    {{ partial "head.html" . }}
  </head>
  <body class="td-{{ .Kind }}{{- if ne (lower .Params.cid) "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">
--- a/layouts/index.headers
+++ b/layouts/index.headers
@ -1,4 +1,4 @@
-{{- if eq (getenv "HUGO_ENV") "production" }}
+{{- if eq hugo.Environment "production" }}
 {{- $cssFilesFromConfig := site.Params.pushAssets.css -}}
 {{- $jsFilesFromConfig := site.Params.pushAssets.js -}}
 {{- $pages := site.RegularPages -}}
--- a/layouts/partials/head.html
+++ b/layouts/partials/head.html
@ -1,5 +1,11 @@
 {{- $isBlogPost := eq .Section "blog" }}
 {{- $ogType := cond (.IsHome) "website" "article" }}
+<!-- per-page robot indexing controls -->
+{{- if hugo.IsProduction -}}
+<meta name="ROBOTS" content="INDEX, FOLLOW">
+{{- else -}}
+<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
+{{- end -}}
 <!-- Global site tag (gtag.js) - Google Analytics -->
 <script async src="https://www.googletagmanager.com/gtag/js?id=UA-36037335-10"></script>
 <script>
@ -19,11 +25,6 @@
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 {{ hugo.Generator }}
-{{ if eq (getenv "HUGO_ENV") "production" }}
-<META NAME="ROBOTS" CONTENT="INDEX, FOLLOW">
-{{ else }}
-<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
-{{ end }}
 {{ range .AlternativeOutputFormats -}}
 <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}">
 {{ end -}}
@ -33,7 +34,7 @@
 {{- template "_internal/google_news.html" . -}}
 {{- template "_internal/schema.html" . -}}
 {{- template "_internal/twitter_cards.html" . -}}
-{{ if eq (getenv "HUGO_ENV") "production" }}
+{{- if hugo.IsProduction -}}
 {{ template "_internal/google_analytics_async.html" . }}
 {{ end }}
 {{ partialCached "head-css.html" . "asdf" }}
--- a/netlify.toml
+++ b/netlify.toml
@ -20,17 +20,10 @@ HUGO_ENABLEGITINFO = "true"
 command = "git submodule update --init --recursive --depth 1 && make deploy-preview"

 [context.branch-deploy]
-command = "git submodule update --init --recursive --depth 1 && make deploy-preview"
+command = "git submodule update --init --recursive --depth 1 && make non-production-build"

-[context.master]
-# This context is triggered by the `master` branch and allows search indexing
+[context.main]
+# This context is triggered by the `main` branch and allows search indexing
 # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads)
 publish = "public"
 command = "git submodule update --init --recursive --depth 1 && make production-build"
-
-# adding in headers to prevent clickjacking
-[[headers]]
-  for = "/*"
-  [headers.values]
-    X-Frame-Options = "DENY"
-    X-XSS-Protection = "1; mode=block"
--- a/static/css/newcommunity.css
+++ b/static/css/newcommunity.css
@ -85,7 +85,7 @@ body {
  font-weight: 300;
  /* letter-spacing:0.03em; */
  /* font-size:15px; */
-  margin: 0 auto;
+  margin: 0;

 }

@ -636,11 +636,9 @@ h2:after {

  body {
    overflow-x: hidden;
-    line-height: 1.5em;
    margin-top: 1%;
    letter-spacing: 0.03em;
    /* font-size: 13px; */
-    margin: 0 auto;

  }