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/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 3a8d8da168..234327094e 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -98,6 +98,9 @@ is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN). +As a result, all namespace names must be valid +[RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + ## Not All Objects are in a Namespace Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 04ca35a5b2..a543ce1e0c 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -88,6 +88,15 @@ has all the information needed to configure a load balancer or proxy server. Mos contains a list of rules matched against all incoming requests. Ingress resource only supports rules for directing HTTP(S) traffic. +If the `ingressClassName` is omitted, a [default Ingress class](#default-ingress-class) +should be defined. + +There are some ingress controllers, that work without the definition of a +default `IngressClass`. For example, the Ingress-NGINX controller can be +configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the +default `IngressClass` as shown [below](#default-ingress-class). + ### Ingress rules Each HTTP rule contains the following information: @@ -339,6 +348,14 @@ an `ingressClassName` specified. You can resolve this by ensuring that at most 1 IngressClass is marked as default in your cluster. {{< /caution >}} +There are some ingress controllers, that work without the definition of a +default `IngressClass`. For example, the Ingress-NGINX controller can be +configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class) +`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the +default `IngressClass`: + +{{< codenew file="service/networking/default-ingressclass.yaml" >}} + ## Types of Ingress ### Ingress backed by a single Service {#single-service-ingress} 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/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md index 7afb3cb249..94c20297cf 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -174,7 +174,7 @@ The output shows that the Container was killed because it is out of memory (OOM) ```shell lastState: terminated: - containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f + containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f exitCode: 137 finishedAt: 2017-06-20T20:52:19Z reason: OOMKilled 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/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 18f840d1e2..6849f22ec0 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -7,8 +7,10 @@ weight: 100 This page shows how to create a Pod that uses a -{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image from a -private container image registry or repository. +{{< glossary_tooltip text="Secret" term_id="secret" >}} to pull an image +from a private container image registry or repository. There are many private +registries in use. This task uses [Docker Hub](https://www.docker.com/products/docker-hub) +as an example registry. {{% thirdparty-content single="true" %}} @@ -18,6 +20,8 @@ private container image registry or repository. * To do this exercise, you need the `docker` command line tool, and a [Docker ID](https://docs.docker.com/docker-id/) for which you know the password. +* If you are using a different private container registry, you need the command + line tool for that registry and any login information for the registry. @@ -59,12 +63,13 @@ The output contains a section similar to this: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. {{< /note >}} -## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials} +## Create a Secret based on existing credentials {#registry-secret-existing-credentials} A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with a container registry to pull a private image. -If you already ran `docker login`, you can copy that credential into Kubernetes: +If you already ran `docker login`, you can copy +that credential into Kubernetes: ```shell kubectl create secret generic regcred \ @@ -77,7 +82,7 @@ secret) then you can customise the Secret before storing it. Be sure to: - set the name of the data item to `.dockerconfigjson` -- base64 encode the docker file and paste that string, unbroken +- base64 encode the Docker configuration file and then paste that string, unbroken as the value for field `data[".dockerconfigjson"]` - set `type` to `kubernetes.io/dockerconfigjson` @@ -213,4 +218,3 @@ kubectl get pod private-reg * Learn more about [adding image pull secrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). * See [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). * See the `imagePullSecrets` field within the [container definitions](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers) of a Pod - 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-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index 759eaf76cd..e6e33efe75 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -70,14 +70,9 @@ spec: Patch your Deployment: -{{< tabs name="kubectl_patch_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment patch-demo --patch $(Get-Content patch-file.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment patch-demo --patch-file patch-file.yaml +``` View the patched Deployment: @@ -183,7 +178,7 @@ spec: Patch your Deployment: ```shell -kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)" +kubectl patch deployment patch-demo --patch-file patch-file-tolerations.yaml ``` View the patched Deployment: @@ -249,7 +244,7 @@ spec: In your patch command, set `type` to `merge`: ```shell -kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)" +kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml ``` View the patched Deployment: @@ -308,14 +303,9 @@ spec: Patch your Deployment: -{{< tabs name="kubectl_retainkeys_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml +``` In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`: @@ -339,14 +329,9 @@ With this patch, we indicate that we want to retain only the `type` key of the ` Patch your Deployment again with this new patch: -{{< tabs name="kubectl_retainkeys2_example" >}} -{{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" -{{< /tab >}} -{{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) -{{< /tab >}}} -{{< /tabs >}} +```shell +kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml +``` Examine the content of the Deployment: @@ -425,10 +410,10 @@ The following commands are equivalent: ```shell -kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" +kubectl patch deployment patch-demo --patch-file patch-file.yaml kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis' -kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" +kubectl patch deployment patch-demo --patch-file patch-file.json kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}' ``` 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/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index fb9c5c3a2e..f9ca81a9b0 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -193,7 +193,7 @@ Below are the procedures to set up autocompletion for Bash, Fish, 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/examples/service/networking/default-ingressclass.yaml b/content/en/examples/service/networking/default-ingressclass.yaml new file mode 100644 index 0000000000..0602ad8c9d --- /dev/null +++ b/content/en/examples/service/networking/default-ingressclass.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + labels: + app.kubernetes.io/component: controller + name: nginx-example + annotations: + ingressclass.kubernetes.io/is-default-class: "true" +spec: + controller: k8s.io/ingress-nginx diff --git a/content/en/examples/service/networking/minimal-ingress.yaml b/content/en/examples/service/networking/minimal-ingress.yaml index 76640b9447..55a5837510 100644 --- a/content/en/examples/service/networking/minimal-ingress.yaml +++ b/content/en/examples/service/networking/minimal-ingress.yaml @@ -5,6 +5,7 @@ metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: + ingressClassName: nginx-example rules: - http: paths: diff --git a/content/en/includes/default-storage-class-prereqs.md b/content/en/includes/default-storage-class-prereqs.md index ef4823318d..57758ef66e 100644 --- a/content/en/includes/default-storage-class-prereqs.md +++ b/content/en/includes/default-storage-class-prereqs.md @@ -1,4 +1,4 @@ -You need to either have a dynamic PersistentVolume provisioner with a default +You need to either have a [dynamic PersistentVolume provisioner](/docs/concepts/storage/dynamic-provisioning/) with a default [StorageClass](/docs/concepts/storage/storage-classes/), or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 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=