diff --git a/Makefile b/Makefile index a103f4e58e..984c261466 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 71f61c6ada..aefa29e1ff 100644 --- 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; diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md index 552f63d948..e6eadaa56f 100644 --- 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} diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index ca026b204f..4b94d933e2 100644 --- 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 diff --git a/content/en/docs/concepts/cluster-administration/system-logs.md b/content/en/docs/concepts/cluster-administration/system-logs.md index 58f123a1c8..9d0359ddad 100644 --- 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 {{}} + 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. diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 1f5bb2e43e..50f7bf62a2 100644 --- 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: diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index f9d2336f07..92ac9529cd 100644 --- 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 diff --git a/content/en/docs/reference/glossary/container-runtime.md b/content/en/docs/reference/glossary/container-runtime.md index 89bd4ae7ad..1d2aae66c6 100644 --- a/content/en/docs/reference/glossary/container-runtime.md +++ b/content/en/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -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). diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md index c8016453cd..e62c5d5e44 100644 --- 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). diff --git a/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md index 2b7ca6144e..9ddb8b4108 100644 --- 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. diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index fbb6d9bc84..b78d6dcd1a 100644 --- 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. +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 <}} +(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. diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index ee4b7a7072..922b01c2ef 100644 --- 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: diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 754da9f7b3..1bd542ab73 100644 --- 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) - - ## 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 diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md index 4090a5374f..bf30d1b42c 100644 --- 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/) diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index a74864fed5..e58b313acb 100644 --- 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 diff --git a/content/en/docs/tasks/network/customize-hosts-file-for-pods.md b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md index e396db5d2d..7eba61fbea 100644 --- 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. diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-fish.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-fish.md new file mode 100644 index 0000000000..a64d0e184c --- /dev/null +++ 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. diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index dcb6e2d6c9..f9ca81a9b0 100644 --- 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) diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md index 676fa968c8..2dc56e5235 100644 --- 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 >}} diff --git a/content/it/_index.html b/content/it/_index.html index 1e5191a982..23f7b881eb 100644 --- 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

- Partecipa alla KubeCon ad Amsterdam (13-16 Agosto 2020) + Partecipa alla KubeCon a Valencia, Spagna + Virtual (16-20 maggio 2022)



- Partecipa alla KubeCon a Boston (17-20 Novembre 2020) + Partecipa al KubeCon a Detroit, Michigan (24-28 ottobre 2022)
diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index a315616af3..fa7e5a34fc 100644 --- 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/)を見てください。 diff --git a/content/ja/docs/concepts/architecture/master-node-communication.md b/content/ja/docs/concepts/architecture/master-node-communication.md index e15d1187ad..d8e6b0f9f5 100644 --- 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サーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。 diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index bf5fa1acb9..2825c7f93d 100644 --- 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" %}} diff --git a/content/ja/docs/concepts/cluster-administration/addons.md b/content/ja/docs/concepts/cluster-administration/addons.md index b2d97790b4..466491cd4c 100644 --- 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/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 ## サービスディスカバリ diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index b6e2c9d0a5..9f27d7779d 100644 --- 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/)のセットアップと管理方法について学んでください。 ## クラスターをセキュアにする diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md index cb9c7c0fc3..d20709e133 100644 --- 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/)を参照してください。 diff --git a/content/ja/docs/concepts/configuration/configmap.md b/content/ja/docs/concepts/configuration/configmap.md index 32799c9e9d..f7d9ea7aa0 100644 --- 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/)を読む。 diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index f775f14b11..6f699bb477 100644 --- 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)を参照する diff --git a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index b3ed117931..a9188037aa 100644 --- 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)を参照してください。 diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index f2a71e1860..0b207bf25f 100644 --- 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の能力について推論することができたとしても、同じネームスペースの別のアプリケーションがその推定を覆すこともあります。 diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md index cb2b457e57..39944f6c30 100644 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -19,7 +19,7 @@ no_list: true ## コンテナイメージ {#container-images} -[コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 +[コンテナイメージ](/ja/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 diff --git a/content/ja/docs/concepts/containers/container-environment.md b/content/ja/docs/concepts/containers/container-environment.md index a311af7803..261f508ca2 100644 --- 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/)のハンズオン diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 50593a61b8..d107478cca 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -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" >}}に新しい種類のオブジェクトを認識させる方法です。 diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index 34e5aa9095..a674087bce 100644 --- 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} diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 714e48e943..d3e647eb78 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -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` diff --git a/content/ja/docs/concepts/overview/working-with-objects/names.md b/content/ja/docs/concepts/overview/working-with-objects/names.md index 25566735bf..3be049c098 100644 --- 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/)を提供しています。 diff --git a/content/ja/docs/concepts/policy/limit-range.md b/content/ja/docs/concepts/policy/limit-range.md index 656ba98a12..64f89c060c 100644 --- a/content/ja/docs/concepts/policy/limit-range.md +++ b/content/ja/docs/concepts/policy/limit-range.md @@ -6,7 +6,7 @@ weight: 10 -デフォルトでは、コンテナは、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やコンテナへの)リソースの割り当てを制限するポリシーを定めることができます。 @@ -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)。 diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index cadcadf0ef..552b518441 100644 --- 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が選択されたときのみ、そのリソースクォータが一致し、消費されます。 diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index cbd833ba3d..d1b249f24e 100644 --- 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/) diff --git a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 3457132bd1..3eeb51376e 100644 --- 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)で処理を詳しく説明しています。 diff --git a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md index e24b960924..6195519928 100644 --- 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` diff --git a/content/ja/docs/concepts/security/pod-security-standards.md b/content/ja/docs/concepts/security/pod-security-standards.md index 7b0f16dff1..098ff119d6 100644 --- 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はどのように扱えばよいでしょうか? diff --git a/content/ja/docs/concepts/services-networking/connect-applications-service.md b/content/ja/docs/concepts/services-networking/connect-applications-service.md index 423b114096..ca2b422113 100644 --- 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 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/)から取得できます。 これにはツールをインストールする必要があります。 diff --git a/content/ja/docs/concepts/services-networking/dual-stack.md b/content/ja/docs/concepts/services-networking/dual-stack.md index 3bad029501..2365680691 100644 --- 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) diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md index b9d60eb6b3..6d0e13d8ee 100644 --- 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/)を読む diff --git a/content/ja/docs/concepts/services-networking/service-topology.md b/content/ja/docs/concepts/services-networking/service-topology.md index 6af79ca7b3..1df3ad8b1e 100644 --- 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/)を読む。 diff --git a/content/ja/docs/concepts/workloads/controllers/cron-jobs.md b/content/ja/docs/concepts/workloads/controllers/cron-jobs.md index 5f820a187a..29a8607c41 100644 --- 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} diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 7d2d55febb..26d611b157 100644 --- 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 diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index de2388ebee..c106a6d71e 100644 --- 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 diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index 1fa4c5c767..160f831969 100644 --- 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/)の例を参考にしてください。 diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 9ef8e0bdf6..9096e1a568 100644 --- 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はリクエストを処理でき、一致するすべてのサービスの負荷分散プールに追加されます。 フィールド名 | 内容 diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md index 4bc7489b5e..25eb4f9fa2 100644 --- 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に参加する diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index caab3b8c11..b8b84402e6 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -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`: ボリュームスナップショットのデータソースサポートを有効にします。 diff --git a/content/ja/docs/reference/glossary/container.md b/content/ja/docs/reference/glossary/container.md index 480934867a..0320a4c302 100644 --- 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: > 軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージです。 diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md index d5ce544edd..98a3a0cc01 100644 --- 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サーバーから取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。 diff --git a/content/ja/docs/reference/glossary/kube-apiserver.md b/content/ja/docs/reference/glossary/kube-apiserver.md index c7a7cfec19..a6c73532d6 100644 --- 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を提供するコントロールプレーンのコンポーネントです。 diff --git a/content/ja/docs/reference/glossary/namespace.md b/content/ja/docs/reference/glossary/namespace.md index 7bc6a0c703..2772ee9140 100644 --- 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: > 同一の物理クラスター上で複数の仮想クラスターをサポートするために使われる抽象概念です。 diff --git a/content/ja/docs/reference/kubectl/cheatsheet.md b/content/ja/docs/reference/kubectl/cheatsheet.md index d93d02551b..d7a636348b 100644 --- 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=` | コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します `-o=custom-columns-file=` | ``ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します `-o=json` | JSON形式のAPIオブジェクトを出力します -`-o=jsonpath=