kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge master into dev-1.21

pull/26152/head
Rey Lejano 2021-01-19 12:39:27 -08:00
parent 14d97e0177 a5630c5dde
commit abef338c9d
144 changed files with 1849 additions and 2419 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile
View File

@ -58,7 +58,7 @@ docker-serve:
@echo -e "$(CCRED)**** The use of docker-serve is deprecated. Use container-serve instead. ****$(CCEND)"
$(MAKE) container-serve
container-image:
container-image: ## Build a container image for the preview of the website
$(CONTAINER_ENGINE) build . \
--network=host \
--tag $(CONTAINER_IMAGE) \
@ -67,7 +67,7 @@ container-image:
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-serve: module-check
container-serve: module-check ## Boot the development server using container. Run `make container-image` before this.
$(CONTAINER_RUN) --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
test-examples:

2
OWNERS_ALIASES
View File

@ -27,6 +27,7 @@ aliases:
- kbarnard10
- kbhawkey
- onlydole
- reylejano
- savitharaghunathan
- sftim
- steveperry-53
@ -136,6 +137,7 @@ aliases:
- seokho-son
- ysyukr
- pjhwa
- yoonian
sig-docs-leads: # Website chairs and tech leads
- irvifa
- jimangel

5
README-uk.md
View File

@ -18,7 +18,8 @@
```bash
git clone https://github.com/kubernetes/website.git
cd website
hugo server --buildFuture
git submodule update --init --recursive --depth 1
make serve
```
<!-- This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. -->
@ -82,4 +83,4 @@ hugo server --buildFuture
## Дякуємо!
<!-- Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! -->
Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію!
Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію!

6
content/en/docs/concepts/cluster-administration/certificates.md
View File

@ -130,11 +130,11 @@ Finally, add the same parameters into the API server start parameters.
Note that you may need to adapt the sample commands based on the hardware
architecture and cfssl version you are using.
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. Create a directory to hold the artifacts and initialize cfssl:

1
content/en/docs/concepts/cluster-administration/system-metrics.md
View File

@ -156,5 +156,4 @@ endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1
## {{% heading "whatsnext" %}}
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)

11
content/en/docs/concepts/configuration/secret.md
View File

@ -24,6 +24,16 @@ a password, a token, or a key. Such information might otherwise be put in a
Pod specification or in an image. Users can create Secrets and the system
also creates some Secrets.
{{< caution >}}
Kubernetes Secrets are, by default, stored as unencrypted base64-encoded
strings. By default they can be retrieved - as plain text - by anyone with API
access, or anyone with access to Kubernetes' underlying data store, etcd. In
order to safely use Secrets, we recommend you (at a minimum):
1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
{{< /caution >}}
<!-- body -->
## Overview of Secrets
@ -795,7 +805,6 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai
Manually created secrets (for example, one containing a token for accessing a GitHub account)
can be automatically attached to pods based on their service account.
See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process.
## Details

3
content/en/docs/concepts/services-networking/ingress-controllers.md
View File

@ -26,6 +26,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
controller.
* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.
* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/).
* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
Citrix Application Delivery Controller.
@ -42,7 +43,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
is an [Istio](https://istio.io/) based ingress controller.
* The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)
is an ingress controller driving [Kong Gateway](https://konghq.com/kong/).
* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/)
works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy).
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an

4
content/en/docs/concepts/services-networking/service.md
View File

@ -134,7 +134,7 @@ For example:
* You want to point your Service to a Service in a different
{{< glossary_tooltip term_id="namespace" >}} or on another cluster.
* You are migrating a workload to Kubernetes. While evaluating the approach,
you run only a proportion of your backends in Kubernetes.
you run only a portion of your backends in Kubernetes.
In any of these scenarios you can define a Service _without_ a Pod selector.
For example:
@ -238,7 +238,7 @@ There are a few reasons for using proxying for Services:
### User space proxy mode {#proxy-mode-userspace}
In this mode, kube-proxy watches the Kubernetes master for the addition and
In this mode, kube-proxy watches the Kubernetes control plane for the addition and
removal of Service and Endpoint objects. For each Service it opens a
port (randomly chosen) on the local node. Any connections to this "proxy port"
are proxied to one of the Service's backend Pods (as reported via

2
content/en/docs/concepts/storage/persistent-volumes.md
View File

@ -231,7 +231,7 @@ the following types of volumes:
* Azure Disk
* Portworx
* FlexVolumes
* CSI
* {{< glossary_tooltip text="CSI" term_id="csi" >}}
You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true.

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

@ -669,13 +669,6 @@ allowVolumeExpansion: true
For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
### PodPreset {#podpreset}
This admission controller injects a pod with the fields specified in a matching PodPreset.
See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
for more information.
### PodSecurityPolicy {#podsecuritypolicy}
This admission controller acts on creation and modification of the pod and determines if it should be admitted

1
content/en/docs/reference/access-authn-authz/rbac.md
View File

@ -86,6 +86,7 @@ Because ClusterRoles are cluster-scoped, you can also use them to grant access t
* cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}})
* non-resource endpoints (like `/healthz`)
* namespaced resources (like Pods), across all namespaces
For example: you can use a ClusterRole to allow a particular user to run
`kubectl get pods --all-namespaces`

18
content/en/docs/reference/glossary/podpreset.md
View File

@ -1,18 +0,0 @@
---
title: PodPreset
id: podpreset
date: 2018-04-12
full_link:
short_description: >
An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time.
aka:
tags:
- operation
---
An API object that injects information such as secrets, volume mounts, and environment variables into {{< glossary_tooltip text="Pods" term_id="pod" >}} at creation time.
<!--more-->
This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.

37
content/en/docs/setup/production-environment/container-runtimes.md
View File

@ -210,7 +210,7 @@ sudo yum update -y && sudo yum install -y containerd.io
```shell
## Configure containerd
sudo mkdir -p /etc/containerd
sudo containerd config default > /etc/containerd/config.toml
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
@ -268,13 +268,12 @@ Use the following commands to install CRI-O on your system:
{{< note >}}
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o).
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
{{< /note >}}
Install and configure prerequisites:
```shell
# Create the .conf file to load the modules at bootup
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
@ -307,9 +306,9 @@ to the appropriate value from the following table:
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@ -343,9 +342,9 @@ To install on the following operating systems, set the environment variable `OS`
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@ -377,9 +376,9 @@ To install on the following operating systems, set the environment variable `OS`
<br />
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
You can pin your installation to a specific release.
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
<br />
Then run
@ -400,7 +399,7 @@ sudo zypper install cri-o
{{% tab name="Fedora" %}}
Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
For instance, if you want to install CRI-O 1.18, `VERSION=1.18`.
For instance, if you want to install CRI-O 1.20, `VERSION=1.20`.
You can find available versions with:
```shell
@ -424,10 +423,26 @@ sudo systemctl daemon-reload
sudo systemctl start crio
```
Refer to the [CRI-O installation guide](https://github.com/kubernetes-sigs/cri-o#getting-started)
Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
for more information.
#### cgroup driver
CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
```toml
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
```
Please also note the changed `conmon_cgroup`, which has to be set to the value
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
in sync.
### Docker

4
content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -21,8 +21,8 @@ For information how to create a cluster with kubeadm once you have performed thi
* One or more machines running one of:
- Ubuntu 16.04+
- Debian 9+
- CentOS 7
- Red Hat Enterprise Linux (RHEL) 7
- CentOS 7+
- Red Hat Enterprise Linux (RHEL) 7+
- Fedora 25+
- HypriotOS v1.0.1+
- Flatcar Container Linux (tested with 2512.3.0)

5
content/en/docs/setup/release/version-skew-policy.md
View File

@ -140,6 +140,11 @@ Pre-requisites:
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
{{< note >}}
Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
In-place minor version `kubelet` upgrades are not supported.
{{</ note >}}
{{< warning >}}
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:

91
content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
View File

@ -1,22 +1,24 @@
---
title: Connect a Front End to a Back End Using a Service
title: Connect a Frontend to a Backend Using Services
content_type: tutorial
weight: 70
---
<!-- overview -->
This task shows how to create a frontend and a backend
microservice. The backend microservice is a hello greeter. The
frontend and backend are connected using a Kubernetes
{{< glossary_tooltip term_id="service" >}} object.
This task shows how to create a _frontend_ and a _backend_ microservice. The backend
microservice is a hello greeter. The frontend exposes the backend using nginx and a
Kubernetes {{< glossary_tooltip term_id="service" >}} object.
## {{% heading "objectives" %}}
* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
* Route traffic to the backend using a frontend.
* Use a Service object to connect the frontend application to the
backend application.
* Create and run a sample `hello` backend microservice using a
{{< glossary_tooltip term_id="deployment" >}} object.
* Use a Service object to send traffic to the backend microservice's multiple replicas.
* Create and run a `nginx` frontend microservice, also using a Deployment object.
* Configure the frontend microservice to send traffic to the backend microservice.
* Use a Service object of `type=LoadBalancer` to expose the frontend microservice
outside the cluster.
## {{% heading "prerequisites" %}}
@ -34,24 +36,24 @@ require a supported environment. If your environment does not support this, you
The backend is a simple hello greeter microservice. Here is the configuration
file for the backend Deployment:
{{< codenew file="service/access/hello.yaml" >}}
{{< codenew file="service/access/backend-deployment.yaml" >}}
Create the backend Deployment:
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
```
View information about the backend Deployment:
```shell
kubectl describe deployment hello
kubectl describe deployment backend
```
The output is similar to this:
```
Name: hello
Name: backend
Namespace: default
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
Labels: app=hello
@ -59,7 +61,7 @@ Labels: app=hello
track=stable
Annotations: deployment.kubernetes.io/revision=1
Selector: app=hello,tier=backend,track=stable
Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
@ -80,14 +82,14 @@ Conditions:
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: hello-3621623197 (7/7 replicas created)
NewReplicaSet: hello-3621623197 (3/3 replicas created)
Events:
...
```
## Creating the backend Service object
## Creating the `hello` Service object
The key to connecting a frontend to a backend is the backend
The key to sending requests from a frontend to a backend is the backend
Service. A Service creates a persistent IP address and DNS name entry
so that the backend microservice can always be reached. A Service uses
{{< glossary_tooltip text="selectors" term_id="selector" >}} to find
@ -95,42 +97,51 @@ the Pods that it routes traffic to.
First, explore the Service configuration file:
{{< codenew file="service/access/hello-service.yaml" >}}
{{< codenew file="service/access/backend-service.yaml" >}}
In the configuration file, you can see that the Service routes traffic to Pods
that have the labels `app: hello` and `tier: backend`.
In the configuration file, you can see that the Service, named `hello` routes
traffic to Pods that have the labels `app: hello` and `tier: backend`.
Create the `hello` Service:
Create the backend Service:
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
```
At this point, you have a backend Deployment running, and you have a
Service that can route traffic to it.
At this point, you have a `backend` Deployment running three replicas of your `hello`
application, and you have a Service that can route traffic to them. However, this
service is neither available nor resolvable outside the cluster.
## Creating the frontend
Now that you have your backend, you can create a frontend that connects to the backend.
The frontend connects to the backend worker Pods by using the DNS name
given to the backend Service. The DNS name is "hello", which is the value
of the `name` field in the preceding Service configuration file.
Now that you have your backend running, you can create a frontend that is accessible
outside the cluster, and connects to the backend by proxying requests to it.
The Pods in the frontend Deployment run an nginx image that is configured
to find the hello backend Service. Here is the nginx configuration file:
The frontend sends requests to the backend worker Pods by using the DNS name
given to the backend Service. The DNS name is `hello`, which is the value
of the `name` field in the `examples/service/access/backend-service.yaml`
configuration file.
{{< codenew file="service/access/frontend.conf" >}}
The Pods in the frontend Deployment run a nginx image that is configured
to proxy requests to the `hello` backend Service. Here is the nginx configuration file:
Similar to the backend, the frontend has a Deployment and a Service. The
configuration for the Service has `type: LoadBalancer`, which means that
the Service uses the default load balancer of your cloud provider.
{{< codenew file="service/access/frontend-nginx.conf" >}}
{{< codenew file="service/access/frontend.yaml" >}}
Similar to the backend, the frontend has a Deployment and a Service. An important
difference to notice between the backend and frontend services, is that the
configuration for the frontend Service has `type: LoadBalancer`, which means that
the Service uses a load balancer provisioned by your cloud provider and will be
accessible from outside the cluster.
{{< codenew file="service/access/frontend-service.yaml" >}}
{{< codenew file="service/access/frontend-deployment.yaml" >}}
Create the frontend Deployment and Service:
```shell
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
```
The output verifies that both resources were created:
@ -178,7 +189,7 @@ cluster.
## Send traffic through the frontend
The frontend and backends are now connected. You can hit the endpoint
The frontend and backend are now connected. You can hit the endpoint
by using the curl command on the external IP of your frontend Service.
```shell
@ -196,17 +207,17 @@ The output shows the message generated by the backend:
To delete the Services, enter this command:
```shell
kubectl delete services frontend hello
kubectl delete services frontend backend
```
To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
```shell
kubectl delete deployment frontend hello
kubectl delete deployment frontend backend
```
## {{% heading "whatsnext" %}}
* Learn more about [Services](/docs/concepts/services-networking/service/)
* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
* Learn more about [DNS for Service and Pods](/docs/concepts/services-networking/dns-pod-service/)

13
content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
View File

@ -314,7 +314,18 @@ CustomResourceDefinitions store validated resource data in the cluster's persist
{{< note >}}
CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`.
For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself.
For legacy CustomResourceDefinition objects created as
`apiextensions.k8s.io/v1beta1` with `spec.preserveUnknownFields` set to
`true`, the following is also true:
* Pruning is not enabled.
* You can store arbitrary data.
For compatibility with `apiextensions.k8s.io/v1`, update your custom
resource definitions to:
1. Use a structural OpenAPI schema.
2. Set `spec.preserveUnknownFields` to `false`.
{{< /note >}}
If you save the following YAML to `my-crontab.yaml`:

323
content/en/docs/tasks/inject-data-application/podpreset.md
View File

@ -1,323 +0,0 @@
---
reviewers:
- jessfraz
title: Inject Information into Pods Using a PodPreset
min-kubernetes-server-version: v1.6
content_type: task
weight: 60
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time.
## {{% heading "prerequisites" %}}
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/).
Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
<!-- steps -->
## Use Pod presets to inject environment variables and volumes
In this step, you create a preset that has a volume mount and one environment variable.
Here is the manifest for the PodPreset:
{{< codenew file="podpreset/preset.yaml" >}}
The name of a PodPreset object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
In the manifest, you can see that the preset has an environment variable definition called `DB_PORT`
and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that
the preset will act upon any Pod that is labeled `role:frontend`.
Create the PodPreset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
Verify that the PodPreset has been created:
```shell
kubectl get podpreset
```
```
NAME CREATED AT
allow-database 2020-01-24T08:54:29Z
```
This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector):
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
Verify that the Pod is running:
```shell
kubectl get pods
```
The output shows that the Pod is running:
```
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 4m
```
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/merged.yaml" >}}
The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation
of the Pod verify that the preset has been applied.
## Pod spec with ConfigMap example
This is an example to show how a Pod spec is modified by a Pod preset
that references a ConfigMap containing environment variables.
Here is the manifest containing the definition of the ConfigMap:
{{< codenew file="podpreset/configmap.yaml" >}}
Create the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml
```
Here is a PodPreset manifest referencing that ConfigMap:
{{< codenew file="podpreset/allow-db.yaml" >}}
Create the preset that references the ConfigMap:
```shell
kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml
```
The following manifest defines a Pod matching the PodPreset for this example:
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
View the Pod spec altered by the admission controller in order to see the effects of the preset
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/allow-db-merged.yaml" >}}
The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod
verify that the preset has been applied.
## ReplicaSet with Pod spec example
This is an example to show that only Pod specs are modified by Pod presets. Other workload types
like ReplicaSets or Deployments are unaffected.
Here is the manifest for the PodPreset for this example:
{{< codenew file="podpreset/preset.yaml" >}}
Create the preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
This manifest defines a ReplicaSet that manages three application Pods:
{{< codenew file="podpreset/replicaset.yaml" >}}
Create the ReplicaSet:
```shell
kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml
```
Verify that the Pods created by the ReplicaSet are running:
```shell
kubectl get pods
```
The output shows that the Pods are running:
```
NAME READY STATUS RESTARTS AGE
frontend-2l94q 1/1 Running 0 2m18s
frontend-6vdgn 1/1 Running 0 2m18s
frontend-jzt4p 1/1 Running 0 2m18s
```
View the `spec` of the ReplicaSet:
```shell
kubectl get replicasets frontend -o yaml
```
{{< note >}}
The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a
`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only
applies to Pod objects.
To see the effects of the preset having been applied, you need to look at individual Pods.
{{< /note >}}
The command to view the specs of the affected Pods is:
```shell
kubectl get pod --selector=role=frontend -o yaml
```
{{< codenew file="podpreset/replicaset-merged.yaml" >}}
Again the `podpreset.admission.kubernetes.io` annotation of the Pods
verifies that the preset has been applied.
## Multiple Pod presets example
This is an example to show how a Pod spec is modified by multiple Pod presets.
Here is the manifest for the first PodPreset:
{{< codenew file="podpreset/preset.yaml" >}}
Create the first PodPreset for this example:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
Here is the manifest for the second PodPreset:
{{< codenew file="podpreset/proxy.yaml" >}}
Create the second preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml
```
Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets):
{{< codenew file="podpreset/pod.yaml" >}}
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
View the Pod spec altered by the admission controller in order to see the effects of both presets
having been applied:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/multi-merged.yaml" >}}
The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io`
annotations of the Pod verify that both presets have been applied.
## Conflict example
This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict.
The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`.
Here is the manifest for the PodPreset:
{{< codenew file="podpreset/conflict-preset.yaml" >}}
Note the `mountPath` value of `/cache`.
Create the preset:
```shell
kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml
```
Here is the manifest for the Pod:
{{< codenew file="podpreset/conflict-pod.yaml" >}}
Note the volumeMount element with the same path as in the PodPreset.
Create the Pod:
```shell
kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml
```
View the Pod spec:
```shell
kubectl get pod website -o yaml
```
{{< codenew file="podpreset/conflict-pod.yaml" >}}
You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod.
However, the
[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
logs a warning containing details of the conflict.
You can view the warning using `kubectl`:
```shell
kubectl -n kube-system logs -l=component=kube-apiserver
```
The output should look similar to:
```
W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""}
does not match
core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""}
in container
```
Note the conflict message on the path for the VolumeMount.
## Deleting a PodPreset
Once you don't need a PodPreset anymore, you can delete it with `kubectl`:
```shell
kubectl delete podpreset allow-database
```
The output shows that the PodPreset was deleted:
```
podpreset "allow-database" deleted
```

9
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -392,8 +392,8 @@ spec:
containers:
- name: my-nginx
resources:
limits:
memory: 512Mi
limits:
memory: 512Mi
EOF
cat <<EOF >./kustomization.yaml
@ -424,11 +424,12 @@ spec:
spec:
containers:
- image: nginx
limits:
memory: 512Mi
name: my-nginx
ports:
- containerPort: 80
resources:
limits:
memory: 512Mi
```
Not all Resources or fields support strategic merge patches. To support modifying arbitrary fields in arbitrary Resources,

2
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -60,7 +60,7 @@ This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://
## Download and install CFSSL
The cfssl tools used in this example can be downloaded at
[https://pkg.cfssl.org/](https://pkg.cfssl.org/).
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
## Create a Certificate Signing Request

204
content/en/docs/tasks/tools/install-kubectl.md
View File

@ -32,34 +32,73 @@ Using the latest version of kubectl helps avoid unforeseen issues.
1. Download the latest release with the command:
```
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
```bash
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
{{< note >}}
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on Linux, type:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
For example, to download version {{< param "fullversion" >}} on Linux, type:
2. Make the kubectl binary executable.
```bash
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
```
{{< /note >}}
```
chmod +x ./kubectl
```
1. Validate the binary (optional)
3. Move the binary in to your PATH.
Download the kubectl checksum file:
```
sudo mv ./kubectl /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
```
```
kubectl version --client
```
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
```
If valid, the output is:
```bash
kubectl: OK
```
If the check fails, `sha256` exits with nonzero status and prints output similar to:
```bash
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Install kubectl
```bash
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
```
{{< note >}}
If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
```bash
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH
```
{{< /note >}}
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
```
### Install using native package management
@ -120,30 +159,65 @@ kubectl version --client
1. Download the latest release:
```bash
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
```
To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version.
{{< note >}}
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
For example, to download version {{< param "fullversion" >}} on macOS, type:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
```
Make the kubectl binary executable.
{{< /note >}}
1. Validate the binary (optional)
Download the kubectl checksum file:
```bash
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
```
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
```
If valid, the output is:
```bash
kubectl: OK
```
If the check fails, `shasum` exits with nonzero status and prints output similar to:
```bash
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
```
{{< note >}}
Download the same version of the binary and checksum.
{{< /note >}}
1. Make the kubectl binary executable.
```bash
chmod +x ./kubectl
```
3. Move the binary in to your PATH.
1. Move the kubectl binary to a file location on your system `PATH`.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl
sudo mv ./kubectl /usr/local/bin/kubectl && \
sudo chown root: /usr/local/bin/kubectl
```
4. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@ -165,7 +239,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
brew install kubernetes-cli
```
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@ -182,7 +256,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
sudo port install kubectl
```
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```bash
kubectl version --client
@ -192,47 +266,72 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
### Install kubectl binary with curl on Windows
1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
Or if you have `curl` installed, use this command:
```bash
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```powershell
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
```
To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt).
{{< note >}}
To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
{{< /note >}}
2. Add the binary in to your PATH.
1. Validate the binary (optional)
3. Test to ensure the version of `kubectl` is the same as downloaded:
Download the kubectl checksum file:
```bash
```powershell
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
```
Validate the kubectl binary against the checksum file:
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
```powershell
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. Add the binary in to your `PATH`.
1. Test to ensure the version of `kubectl` is the same as downloaded:
```cmd
kubectl version --client
```
{{< note >}}
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH.
If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
{{< /note >}}
### Install with Powershell from PSGallery
### Install with PowerShell from PSGallery
If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell.
1. Run the installation commands (making sure to specify a `DownloadLocation`):
```powershell
Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
```
```
{{< note >}}
If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory.
{{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file.
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```powershell
kubectl version --client
@ -260,32 +359,32 @@ Updating the installation is performed by rerunning the two commands listed in s
{{< /tabs >}}
2. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```powershell
kubectl version --client
```
3. Navigate to your home directory:
1. Navigate to your home directory:
```powershell
# If you're using cmd.exe, run: cd %USERPROFILE%
cd ~
```
4. Create the `.kube` directory:
1. Create the `.kube` directory:
```powershell
mkdir .kube
```
5. Change to the `.kube` directory you just created:
1. Change to the `.kube` directory you just created:
```powershell
cd .kube
```
6. Configure kubectl to use a remote Kubernetes cluster:
1. Configure kubectl to use a remote Kubernetes cluster:
```powershell
New-Item config -type file
@ -301,13 +400,13 @@ You can install kubectl as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the `kubectl` installation command:
1. Run the `kubectl` installation command:
```shell
gcloud components install kubectl
```
3. Test to ensure the version you installed is up-to-date:
1. Test to ensure the version you installed is up-to-date:
```shell
kubectl version --client
@ -385,11 +484,13 @@ You now need to ensure that the kubectl completion script gets sourced in all yo
```bash
echo 'source <(kubectl completion bash)' >>~/.bashrc
```
- Add the completion script to the `/etc/bash_completion.d` directory:
```bash
kubectl completion bash >/etc/bash_completion.d/kubectl
```
If you have an alias for kubectl, you can extend shell completion to work with that alias:
```bash
@ -470,7 +571,6 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
```bash
echo 'source <(kubectl completion bash)' >>~/.bash_profile
```
- Add the completion script to the `/usr/local/etc/bash_completion.d` directory:

25
content/en/examples/examples_test.go
View File

@ -32,7 +32,6 @@ import (
"k8s.io/apimachinery/pkg/types"
"k8s.io/apimachinery/pkg/util/validation/field"
"k8s.io/apimachinery/pkg/util/yaml"
// "k8s.io/apiserver/pkg/util/feature"
"k8s.io/kubernetes/pkg/api/legacyscheme"
"k8s.io/kubernetes/pkg/apis/apps"
@ -56,9 +55,6 @@ import (
"k8s.io/kubernetes/pkg/apis/rbac"
rbac_validation "k8s.io/kubernetes/pkg/apis/rbac/validation"
"k8s.io/kubernetes/pkg/apis/settings"
settings_validation "k8s.io/kubernetes/pkg/apis/settings/validation"
"k8s.io/kubernetes/pkg/apis/storage"
storage_validation "k8s.io/kubernetes/pkg/apis/storage/validation"
@ -73,7 +69,6 @@ import (
_ "k8s.io/kubernetes/pkg/apis/networking/install"
_ "k8s.io/kubernetes/pkg/apis/policy/install"
_ "k8s.io/kubernetes/pkg/apis/rbac/install"
_ "k8s.io/kubernetes/pkg/apis/settings/install"
_ "k8s.io/kubernetes/pkg/apis/storage/install"
)
@ -111,7 +106,6 @@ func initGroups() {
networking.GroupName,
policy.GroupName,
rbac.GroupName,
settings.GroupName,
storage.GroupName,
}
@ -296,11 +290,6 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) {
case *rbac.ClusterRoleBinding:
// clusterolebinding does not accept namespace
errors = rbac_validation.ValidateClusterRoleBinding(t)
case *settings.PodPreset:
if t.Namespace == "" {
t.Namespace = api.NamespaceDefault
}
errors = settings_validation.ValidatePodPreset(t)
case *storage.StorageClass:
// storageclass does not accept namespace
errors = storage_validation.ValidateStorageClass(t)
@ -518,20 +507,6 @@ func TestExampleObjectSchemas(t *testing.T) {
"node-problem-detector-configmap": {&apps.DaemonSet{}},
"termination": {&api.Pod{}},
},
"podpreset": {
"allow-db": {&settings.PodPreset{}},
"allow-db-merged": {&api.Pod{}},
"configmap": {&api.ConfigMap{}},
"conflict-pod": {&api.Pod{}},
"conflict-preset": {&settings.PodPreset{}},
"merged": {&api.Pod{}},
"multi-merged": {&api.Pod{}},
"pod": {&api.Pod{}},
"preset": {&settings.PodPreset{}},
"proxy": {&settings.PodPreset{}},
"replicaset-merged": {&api.Pod{}},
"replicaset": {&apps.ReplicaSet{}},
},
"pods": {
"commands": {&api.Pod{}},
"init-containers": {&api.Pod{}},

31
content/en/examples/podpreset/allow-db-merged.yaml
View File

@ -1,31 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumes:
- name: cache-volume
emptyDir: {}

24
content/en/examples/podpreset/allow-db.yaml
View File

@ -1,24 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
- name: duplicate_key
value: FROM_ENV
- name: expansion
value: $(REPLACE_ME)
envFrom:
- configMapRef:
name: etcd-env-config
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}

14
content/en/examples/podpreset/configmap.yaml
View File

@ -1,14 +0,0 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: etcd-env-config
data:
number_of_members: "1"
initial_cluster_state: new
initial_cluster_token: DUMMY_ETCD_INITIAL_CLUSTER_TOKEN
discovery_token: DUMMY_ETCD_DISCOVERY_TOKEN
discovery_url: http://etcd_discovery:2379
etcdctl_peers: http://etcd:2379
duplicate_key: FROM_CONFIG_MAP
REPLACE_ME: "a value"

19
content/en/examples/podpreset/conflict-pod.yaml
View File

@ -1,19 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}

18
content/en/examples/podpreset/conflict-preset.yaml
View File

@ -1,18 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
volumeMounts:
- mountPath: /cache
name: other-volume
volumes:
- name: other-volume
emptyDir: {}

25
content/en/examples/podpreset/merged.yaml
View File

@ -1,25 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
volumes:
- name: cache-volume
emptyDir: {}

29
content/en/examples/podpreset/multi-merged.yaml
View File

@ -1,29 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
podpreset.admission.kubernetes.io/podpreset-proxy: "resource version"
spec:
containers:
- name: website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
- mountPath: /etc/proxy/configs
name: proxy-volume
ports:
- containerPort: 80
env:
- name: DB_PORT
value: "6379"
volumes:
- name: cache-volume
emptyDir: {}
- name: proxy-volume
emptyDir: {}

14
content/en/examples/podpreset/pod.yaml
View File

@ -1,14 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: website
labels:
app: website
role: frontend
spec:
containers:
- name: website
image: nginx
ports:
- containerPort: 80

17
content/en/examples/podpreset/preset.yaml
View File

@ -1,17 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
spec:
selector:
matchLabels:
role: frontend
env:
- name: DB_PORT
value: "6379"
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}

14
content/en/examples/podpreset/proxy.yaml
View File

@ -1,14 +0,0 @@
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: proxy
spec:
selector:
matchLabels:
role: frontend
volumeMounts:
- mountPath: /etc/proxy/configs
name: proxy-volume
volumes:
- name: proxy-volume
emptyDir: {}

31
content/en/examples/podpreset/replicaset-merged.yaml
View File

@ -1,31 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: frontend
labels:
app: guestbook
role: frontend
annotations:
podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /cache
name: cache-volume
env:
- name: GET_HOSTS_FROM
value: dns
- name: DB_PORT
value: "6379"
ports:
- containerPort: 80
volumes:
- name: cache-volume
emptyDir: {}

29
content/en/examples/podpreset/replicaset.yaml
View File

@ -1,29 +0,0 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
role: frontend
matchExpressions:
- {key: role, operator: In, values: [frontend]}
template:
metadata:
labels:
app: guestbook
role: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80

2
content/en/examples/service/access/Dockerfile
View File

@ -1,4 +1,4 @@
FROM nginx:1.17.3
RUN rm /etc/nginx/conf.d/default.conf
COPY frontend.conf /etc/nginx/conf.d
COPY frontend-nginx.conf /etc/nginx/conf.d

6
content/en/examples/service/access/hello.yaml → content/en/examples/service/access/backend-deployment.yaml
View File

@ -1,14 +1,15 @@
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello
name: backend
spec:
selector:
matchLabels:
app: hello
tier: backend
track: stable
replicas: 7
replicas: 3
template:
metadata:
labels:
@ -22,3 +23,4 @@ spec:
ports:
- name: http
containerPort: 80
...

2
content/en/examples/service/access/hello-service.yaml → content/en/examples/service/access/backend-service.yaml
View File

@ -1,3 +1,4 @@
---
apiVersion: v1
kind: Service
metadata:
@ -10,3 +11,4 @@ spec:
- protocol: TCP
port: 80
targetPort: http
...

27
content/en/examples/service/access/frontend-deployment.yaml Normal file
View File

@ -0,0 +1,27 @@
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
lifecycle:
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
...

14
content/en/examples/service/access/frontend-nginx.conf Normal file
View File

@ -0,0 +1,14 @@
# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
# hello is the internal DNS name used by the backend Service inside Kubernetes
server hello;
}
server {
listen 80;
location / {
# The following statement will proxy traffic to the upstream named Backend
proxy_pass http://Backend;
}
}

15
content/en/examples/service/access/frontend-service.yaml Normal file
View File

@ -0,0 +1,15 @@
---
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
...

11
content/en/examples/service/access/frontend.conf
View File

@ -1,11 +0,0 @@
upstream hello {
server hello;
}
server {
listen 80;
location / {
proxy_pass http://hello;
}
}

39
content/en/examples/service/access/frontend.yaml
View File

@ -1,39 +0,0 @@
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
lifecycle:
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]

2
content/fr/examples/application/guestbook/frontend-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend

2
content/fr/examples/application/guestbook/redis-master-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-master

2
content/fr/examples/application/guestbook/redis-slave-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-slave

28
content/id/docs/reference/glossary/kuantitas.md
View File

@ -1,28 +0,0 @@
---
title: Kuantitas
id: kuantitas
date: 2018-08-07
full_link:
short_description: >
Representasi bilangan bulat dari bilangan kecil atau bilangan besar menggunakan sufiks SI.
aka:
tags:
- core-object
---
Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI.
<!--lebih lanjut-->
Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi
bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili,
sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai` 1k`, dan `1000000` sebagai` 1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat
ditulis sebagai `2Ki`.
Satuan desimal yang diterima (pangkat 10) adalah `m` (mili),` k` (kilo,
sengaja huruf kecil), `M` (mega),` G` (giga), `T` (tera),` P` (peta),
`E` (exa).
Unit biner (pangkat-2) yang diterima adalah `Ki` (kibi),` Mi` (mebi), `Gi` (gibi),` Ti` (tebi), `Pi` (pebi),` Ei` (exbi).

7
content/id/docs/reference/glossary/kube-controller-manager.md
View File

@ -4,16 +4,15 @@ id: kube-controller-manager
date: 2019-04-21
full_link: /docs/reference/generated/kube-controller-manager/
short_description: >
Komponen di master yang menjalankan kontroler.
Komponen _control plane_ yang menjalankan pengontrol.
aka:
tags:
- architecture
- fundamental
---
Komponen di master yang menjalankan kontroler.
Komponen _control plane_ yang menjalankan pengontrol.
<!--more-->
Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah <i> binary </i> yang dijalankan sebagai satu proses.
Secara logis, setiap pengontrol adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kesemuanya dikompilasi menjadi sebuah biner (_binary_) yang dijalankan sebagai satu proses.

20
content/id/docs/reference/glossary/kube-proxy.md Normal file
View File

@ -0,0 +1,20 @@
---
title: kube-proxy
id: kube-proxy
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy` merupakan proksi jaringan yang berjalan pada setiap node di dalam klaster.
aka:
tags:
- fundamental
- networking
---
kube-proxy merupakan proksi jaringan yang berjalan pada setiap {{< glossary_tooltip term_id="node" >}} di dalam klastermu, yang mengimplementasikan bagian dari konsep {{< glossary_tooltip text="layanan" term_id="service">}} Kubernetes.
<!--more-->
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) mengelola aturan jaringan pada node. Aturan jaringan tersebut memungkinkan komunikasi jaringan ke Pod-mu melalui sesi jaringan dari dalam ataupun luar klaster.
kube-proxy menggunakan lapisan pemfilteran paket sistem operasi jika ada dan tersedia. Jika tidak, maka kube-proxy akan meneruskan lalu lintas jaringan itu sendiri.

7
content/id/docs/reference/glossary/kube-scheduler.md
View File

@ -4,15 +4,14 @@ id: kube-scheduler
date: 2019-04-21
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-<i>assign</i> ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan.
Komponen _control plane_ yang bertugas mengamati Pod baru yang belum ditempatkan di node manapun dan kemudian memilihkan node di mana Pod baru tersebut akan dijalankan.
aka:
tags:
- architecture
---
Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-<i>assign</i> ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan.
Komponen _control plane_ yang bertugas mengamati {{< glossary_tooltip term_id="pod" >}} baru yang belum ditempatkan di node manapun dan kemudian memilihkan {{< glossary_tooltip term_id="node" >}} di mana Pod baru tersebut akan dijalankan.
<!--more-->
Faktor-faktor yang diperhatikan dalam proses ini adalah kebutuhan <i>resource</i> secara individual dan kolektif, konstrain perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan non-afinitas, lokalisasi data, interferensi <i>inter-workload</i> dan <i>deadlines</i>.
Faktor-faktor yang dipertimbangkan untuk keputusan penjadwalan termasuk: kebutuhan sumber daya secara individual dan kolektif, batasan perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan nonafinitas, lokalisasi data, interferensi antar beban kerja dan tenggat waktu.

2
content/id/docs/reference/glossary/kubectl.md
View File

@ -11,7 +11,7 @@ tags:
- tool
- fundamental
---
Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server {{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}.
Sebuah utilitas baris perintah untuk berkomunikasi dengan suatu server {{< glossary_tooltip term_id="kubernetes-api" >}}.
<!--more-->

5
content/id/docs/reference/glossary/kubelet.md
View File

@ -4,12 +4,11 @@ id: kubelet
date: 2019-04-21
full_link: /docs/reference/generated/kubelet
short_description: >
Agen yang dijalankan pada setiap <i>node</i> di klaster dan bertugas memastikan kontainer dijalankan di dalam pod.
Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod.
aka:
tags:
- fundamental
- core-object
---
Agen yang dijalankan pada setiap <i>node</i> di klaster dan bertugas memastikan kontainer dijalankan di dalam pod.
Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod.

22
content/id/docs/reference/glossary/quantity.md Normal file
View File

@ -0,0 +1,22 @@
---
title: Kuantitas
id: quantity
date: 2018-08-07
full_link:
short_description: >
Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI.
aka:
tags:
- core-object
---
Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI.
<!--more-->
Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
Satuan desimal yang diterima (pangkat 10) adalah `m` (mili), `k` (kilo, sengaja huruf kecil), `M` (mega), `G` (giga), `T` (tera), `P` (peta), `E` (exa).
Unit biner (pangkat 2) yang diterima adalah `Ki` (kibi), `Mi` (mebi), `Gi` (gibi), `Ti` (tebi), `Pi` (pebi), `Ei` (exbi).

4
content/id/docs/setup/production-environment/container-runtimes.md
View File

@ -359,7 +359,7 @@ apt-get update && apt-get install -y containerd.io
```shell
# Mengonfigure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
@ -391,7 +391,7 @@ yum update -y && yum install -y containerd.io
```shell
## Mengonfigurasi containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell

2
content/id/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -426,7 +426,7 @@ pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan ba
## Lampiran: Kuantitas
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="kuantitas" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti Anda mungkin melihat nilai metrik Anda berfluktuasi antara `1` dan` 1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
## Lampiran: Skenario lain yang memungkinkan

2
content/ja/docs/concepts/configuration/secret.md
View File

@ -457,7 +457,7 @@ Secretは直接Podが参照できるようにはされず、システムの別
PodのボリュームとしてSecretを使うには、
1. Secretを作成するか既存のものを使用します。複数のPodが同一のSecretを参照することができます。
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。
1. Secretを必要とするそれぞれのコンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して`.spec.containers[].volumeMounts[].mountPath`をSecretをマウントする未使用のディレクトリ名にします。
1. イメージやコマンドラインを変更し、プログラムがそのディレクトリを参照するようにします。連想配列`data`のキーは`mountPath`以下のファイル名になります。

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

@ -105,19 +105,6 @@ APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token
ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。
### 静的なパスワードファイル
APIサーバーに`--basic-auth-file=SOMEFILE`オプションを渡すことで、Basic認証を有効にすることができます。現在のところ、Basic認証の認証情報は有効期限が無く、APIサーバーを再起動しない限りパスワードを変更することはできません。よりセキュアなモードをさらに使いやすくするための改良が完了するまでの間、現時点では利便性のためにBasic認証がサポートされていることに注意してください。
Basic認証ファイルは、トークン、ユーザー名、ユーザーIDの少なくとも3つの列を持つcsvファイルです。
Kubernetesのバージョン1.6以降では、オプションとしてカンマ区切りのグループ名を含む4列目を指定することができます。複数のグループがある場合は、4列目の値をダブルクォート(")で囲む必要があります。以下の例を参照してください。
```conf
password,user,uid,"group1,group2,group3"
```
HTTPクライアントからBasic認証を利用する場合、APIサーバーは`Basic BASE64ENCODED(USER:PASSWORD)`の値を持つ`Authorization`ヘッダーを待ち受けます。
### サービスアカウントトークン
サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。

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

@ -351,7 +351,7 @@ apt-get update && apt-get install -y containerd.io
```shell
# containerdの設定
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
@ -383,7 +383,7 @@ yum update -y && yum install -y containerd.io
```shell
## containerdの設定
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell

62
content/ko/community/static/cncf-code-of-conduct.md
View File

@ -2,44 +2,44 @@
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
## CNCF 커뮤니티 행동 강령 v1.0
### 참여자 행동 강령
### 기여자 행동 강령
본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를
육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며,
pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는
모든 분들을 존중하겠다고 약속드립니다.
본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트,
풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는
모든 분들을 존중할 것을 약속합니다.
저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향,
장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는
국적에 상관 없이 모두가 괴롭힘 없는 환경에서
본 프로젝트에 참여하도록 최선을 다하고 있습니다.
우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression),
성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교,
또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에
참여할 수 있도록 최선을 다하고 있습니다.
참여자에게 금지하는 행동의 예는 다음과 같습니다.:
참여자에게 금지하는 행위의 예시는 다음과 같습니다.
* 성적 언어 또는 이미지 사용
* 개인적인 공격
* 시비 걸기 또는 모욕/경멸적인 코멘트
* 공적 및 사적 괴롭힘
* 분명한 허락을 받지 않은 타인의 사적 정보 출판,
예를 들어 물리적 또는 전자 주소
* 다른 비윤리적 또는 비전문적인 행동
- 성적인 언어 또는 이미지 사용
- 인신 공격
- 도발적이거나 모욕/경멸적인 코멘트
- 공개적이거나 사적인 괴롭힘
- 타인의 주소 및 전자주소와 같은 개인 정보의
동의 없는 공개
- 기타 비윤리적이거나 비전문적인 행동
프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령,
위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과
책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본
프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을
적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는
행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다.
프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit),
코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정,
거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의
모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다.
행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서
영구적으로 제적될 수 있습니다.
본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는
그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다.
본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트
또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 <conduct@kubernetes.io>를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 <mishi@linux.com>으로 연락하십시오.
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의해 주시기 바랍니다.
본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의
버전 1.2.0을 적용하였으며,
해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다.
본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서
제공하는 버전 1.2.0을 적용하였으며, 해당 내용은
https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다.
### CNCF 커뮤니티 행동 강령
### CNCF 이벤트 행동 강령
CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다.
CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다.

2
content/ko/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
사용한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
### API 서버에서 노드, 파드 및 서비스로의 통신

2
content/ko/docs/concepts/cluster-administration/_index.md
View File

@ -60,7 +60,7 @@ no_list: true
### kubelet 보안
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스

5
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
View File

@ -1,4 +1,5 @@
---
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
@ -6,7 +7,7 @@ weight: 70
<!-- overview -->
가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다.
@ -20,7 +21,7 @@ weight: 70
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
이미지들을 삭제한다.

32
content/ko/docs/concepts/cluster-administration/system-metrics.md
View File

@ -1,18 +1,19 @@
---
title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
content_type: concept
weight: 60
aliases:
- controller-metrics.md
---
<!-- overview -->
시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다.
쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
<!-- body -->
@ -49,18 +50,20 @@ rules:
## 메트릭 라이프사이클
알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제
알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭
알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다.
안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다.
안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다.
* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다.
* 안정적인 메트릭의 유형(type)은 수정되지 않는다.
* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다
* 메트릭 유형은 수정되지 않는다
사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다.
이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다.
사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다.
예를 들면,
사용 중단되기 전에는 아래와 같다.
* 사용 중단 이전에는 다음과 같다.
```
# HELP some_counter this counts things
@ -68,7 +71,7 @@ rules:
some_counter 0
```
사용 중단된 이후에는 아래와 같다.
* 사용 중단 이후에는 다음과 같다.
```
# HELP some_counter (Deprecated since 1.15.0) this counts things
@ -76,9 +79,9 @@ some_counter 0
some_counter 0
```
메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다.
히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다.
메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다.
삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다.
## 히든 메트릭 표시
@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
### kube-scheduler 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}

3
content/ko/docs/concepts/configuration/configmap.md
View File

@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
모든 요청을 리디렉션할 수 있다.
따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
@ -262,12 +261,10 @@ data:
immutable: true
```
{{< note >}}
컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
{{< /note >}}
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/configuration/secret.md
View File

@ -349,7 +349,7 @@ data:
부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.
- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항.

4
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -17,8 +17,8 @@ card:
최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할
수 있도록 HTTP API를 제공한다.
쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다.
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/)
커맨드 라인 인터페이스 또는 API를 사용하는

13
content/ko/docs/concepts/overview/working-with-objects/common-labels.md
View File

@ -58,14 +58,14 @@ metadata:
## 애플리케이션과 애플리케이션 인스턴스
애플리케이션은 동일한 쿠버네티스 클러스터에,
애플리케이션은 동일한 쿠버네티스 클러스터에,
심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에
워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다.
예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며,
애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에
`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를
식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.
## 예시
@ -169,4 +169,3 @@ metadata:
```
MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.

30
content/ko/docs/concepts/policy/pod-security-policy.md
View File

@ -1,4 +1,7 @@
---
title: 파드 시큐리티 폴리시
content_type: concept
weight: 30
@ -213,12 +216,17 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
name: pause
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
EOF
```
이것의 출력은 다음과 같을 것이다.
```
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
```
@ -261,12 +269,17 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
name: pause
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
EOF
```
이것의 출력은 다음과 같을 것이다.
```
pod "pause" created
```
@ -278,14 +291,19 @@ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: privileged
name: privileged
spec:
containers:
- name: pause
- name: pause
image: k8s.gcr.io/pause
securityContext:
privileged: true
EOF
```
이것의 출력은 다음과 같을 것이다.
```
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
```

2
content/ko/docs/concepts/policy/resource-quotas.md
View File

@ -186,7 +186,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.

4
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -77,8 +77,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지
방법이 있다.
1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -420,5 +420,5 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.

75
content/ko/docs/concepts/workloads/_index.md
View File

@ -8,50 +8,73 @@ no_list: true
{{< glossary_definition term_id="workload" length="short" >}}
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
집합을 나타낸다.
파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다.
예를 들어, 일단 파드가 클러스터에서 실행되고 나서
해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에
심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다.
그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다.
대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
구성한다.
이러한 워크로드 리소스에는 다음이 포함된다.
쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.
* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
(레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체);
* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/);
* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는
파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
* 완료될 때까지 실행되는 작업에 대한
[잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)
* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)
(레거시 리소스
{{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체).
`Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우,
클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는
어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가
데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와
[`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다.
전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의
다른 `Pods` 로 데이터를 복제할 수 있다.
* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다.
이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.
예를 들면, 네트워킹 지원 도구 또는
{{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다.
`DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다,
컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다.
* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은
실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면,
잡은 단 한 번의 작업을 나타낸다.
관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
제거된 후 클러스터에서 오브젝트를 정리한다.
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드
리소스도 찾을 수 있다.
[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면,
쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를
추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되
_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은),
사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.
## {{% heading "whatsnext" %}}
각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
* 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,
[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다.
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
두 가지 개념이다.
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
제거된 후 클러스터에서 오브젝트를 정리한다.
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
사용하거나, 웹 애플리케이션의 경우에만
[인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
메커니즘에 대해 알아볼 수도 있다.

34
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -1,4 +1,8 @@
---
title: 크론잡
content_type: concept
weight: 80
@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는
([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
이 예시를 더 자세히 설명한다.)
### 크론 스케줄 문법
```
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
```
| 항목 | 설명 | 상응 표현 |
| ------------- | ------------- |------------- |
| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * |
| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * |
| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 |
| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * |
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
`0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
## 크론잡의 한계 {#cron-job-limitations}
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는

15
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -1,4 +1,7 @@
---
title: 잡
content_type: concept
feature:
@ -35,6 +38,7 @@ weight: 50
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
```
출력 결과는 다음과 같다.
```
job.batch/pi created
```
@ -44,6 +48,7 @@ job.batch/pi created
```shell
kubectl describe jobs/pi
```
출력 결과는 다음과 같다.
```
Name: pi
Namespace: default
@ -88,6 +93,7 @@ Events:
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods
```
출력 결과는 다음과 같다.
```
pi-5rwd7
```
@ -100,7 +106,7 @@ pi-5rwd7
```shell
kubectl logs $pods
```
다음과 유사하게 출력된다.
출력 결과는 다음과 같다.
```shell
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
@ -395,10 +401,11 @@ spec:
잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
```
```shell
kubectl get job old -o yaml
```
```
출력 결과는 다음과 같다.
```yaml
kind: Job
metadata:
name: old
@ -417,7 +424,7 @@ spec:
시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해
새 잡에서 `manualSelector: true` 를 지정해야 한다.
```
```yaml
kind: Job
metadata:
name: new

30
content/ko/docs/concepts/workloads/pods/_index.md
View File

@ -1,4 +1,6 @@
---
title: 파드
content_type: concept
weight: 10
@ -189,6 +191,34 @@ spec:
시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
확장할 수 있게 한다.
## 파드 갱신 및 교체
이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드
템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신
갱신된 템플릿을 기반으로 신규 파드를 생성한다.
쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다.
동작 중인 파드의 필드를 갱신하는 것도 가능하다.
그러나,
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은
파드 갱신 작업에는 다음과 같은 제약이 있다.
- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
`namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다.
그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
갱신만 허용한다.
- `metadata.deletionTimestamp` 가 설정된 경우,
`metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다.
- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`,
`spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는
변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
허용한다.
1. 지정되지 않은 필드를 양수로 설정;
1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
## 리소스 공유와 통신
파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을

6
content/ko/docs/concepts/workloads/pods/init-containers.md
View File

@ -1,4 +1,6 @@
---
title: 초기화 컨테이너
content_type: concept
weight: 40
@ -47,9 +49,9 @@ weight: 40
또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다.
왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을
한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을
모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을
초기화하고 평소와 같이 실행한다.
## 초기화 컨테이너 사용하기

6
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -66,7 +66,7 @@ graph TB
API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
```
```yaml
apiVersion: v1
kind: Pod
metadata:
@ -290,7 +290,7 @@ graph BT
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
@ -315,7 +315,7 @@ profiles:
{{< note >}}
기본 스케줄링 제약 조건에 의해 생성된 점수는
[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
의해 생성된 점수와 충돌 할 수 있다.
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
이 플러그인을 비활성화 하는 것을 권장한다.

6
content/ko/docs/reference/_index.md
View File

@ -1,5 +1,7 @@
---
title: 레퍼런스
linkTitle: "레퍼런스"
main_menu: true
weight: 70
@ -16,7 +18,7 @@ content_type: concept
## API 레퍼런스
* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)
* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
## API 클라이언트 라이브러리
@ -33,7 +35,7 @@ content_type: concept
## CLI 레퍼런스
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
## 컴포넌트 레퍼런스

10
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -419,10 +419,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
참고한다.
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
확인한다.
- `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다.
-`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
@ -508,7 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
[엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다.
-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다.
- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
- `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
@ -582,7 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다.
- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다.
- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다.
자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다.

19
content/ko/docs/reference/glossary/dynamic-volume-provisioning.md Normal file
View File

@ -0,0 +1,19 @@
---
title: 동적 볼륨 프로비저닝(Dynamic Volume Provisioning)
id: dynamicvolumeprovisioning
date: 2018-04-12
full_link: /ko/docs/concepts/storage/dynamic-provisioning
short_description: >
사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다.
aka:
tags:
- core-object
- storage
---
사용자가 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 자동 생성을 요청할 수 있게 해준다.
<!--more-->
동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 기반으로 한다. 이 스토리지클래스는 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 및 {{< glossary_tooltip text="볼륨 플러그인" term_id="volume-plugin" >}}에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다.

4
content/ko/docs/reference/glossary/kube-proxy.md
View File

@ -18,10 +18,10 @@ tags:
<!--more-->
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는
[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는
노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크
세션이나 클러스터 바깥에서 파드로 네트워크 통신을
할 수 있도록 해준다.
kube-proxy는 운영 체제에 가용한 패킷
kube-proxy는 운영 체제에 가용한 패킷
필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

10
content/ko/docs/reference/kubectl/cheatsheet.md
View File

@ -356,8 +356,8 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든
`-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력
`-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력
`-o=json` | JSON 형식의 API 오브젝트 출력
`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
`-o=jsonpath=<템플릿>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력
`-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음
`-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함
`-o=yaml` | YAML 형식의 API 오브젝트 출력
@ -395,10 +395,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
## {{% heading "whatsnext" %}}
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자.
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.
* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다.
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다.
* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.

12
content/ko/docs/reference/kubectl/overview.md
View File

@ -119,7 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags]
`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
## 리소스 타입
@ -188,7 +188,7 @@ kubectl [command] [TYPE] [NAME] [flags]
## 출력 옵션
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
### 출력 서식화
@ -207,8 +207,8 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
`-o json` | JSON 형식의 API 오브젝트를 출력한다.
`-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
`-o name` | 리소스 이름만 출력한다.
`-o wide` | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
`-o yaml` | YAML 형식의 API 오브젝트를 출력한다.
@ -222,7 +222,7 @@ kubectl get pod web-pod-13je7 -o yaml
```
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
[kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
#### 사용자 정의 열 {#custom-columns}
@ -282,7 +282,7 @@ pod-name 1m
### 오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
#### 구문

1
content/ko/docs/reference/using-api/client-libraries.md
View File

@ -73,6 +73,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
| Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) |
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |

32
content/ko/docs/setup/production-environment/container-runtimes.md
View File

@ -1,4 +1,7 @@
---
title: 컨테이너 런타임
content_type: concept
weight: 20
@ -122,6 +125,24 @@ sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Ubuntu 18.04/20.04" %}}
```shell
# (containerd 설치)
sudo apt-get update && sudo apt-get install -y containerd
```
```shell
# containerd 구성
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
@ -151,7 +172,7 @@ sudo yum update -y && sudo yum install -y containerd.io
```shell
## containerd 구성
sudo mkdir -p /etc/containerd
sudo containerd config default > /etc/containerd/config.toml
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
@ -167,7 +188,6 @@ cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.
cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
```
```shell
```powershell
# 추출 및 구성
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
@ -262,6 +282,7 @@ curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/
sudo apt-get update
sudo apt-get install cri-o cri-o-runc
```
{{% /tab %}}
{{% tab name="Ubuntu" %}}
@ -361,11 +382,14 @@ sudo systemctl start crio
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
참고한다.
### 도커
각 노드에 도커 CE를 설치한다.
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는 도커 버전을 찾을 수 있다.
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는
도커 버전을 찾을 수 있다.
사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다.
@ -388,7 +412,7 @@ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring
```shell
# 도커 apt 리포지터리 추가:
sudo add-apt-repository \
deb [arch=amd64] https://download.docker.com/linux/ubuntu \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```

8
content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md
View File

@ -11,8 +11,8 @@ weight: 100
kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록
해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을
통해 kubelet에 구성된 [스태틱(static) 파드](/docs/tasks/configure-pod-container/static-pod/)
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/docs/concepts/workloads/controllers/daemonset/)
통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)
대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/)
로 실행된다.
자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)
@ -32,7 +32,7 @@ kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플
_컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._
1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는
[`hostPath`](/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
[`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온
자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해
관리되지 않는다.
@ -63,5 +63,3 @@ kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플
1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은
리스닝 포트에 바인딩하여 활성화할 수 있다.

5
content/ko/docs/setup/production-environment/tools/kubespray.md
View File

@ -22,7 +22,7 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
* Flatcar Container Linux by Kinvolk
* 지속적인 통합 (CI) 테스트
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
<!-- body -->
@ -103,7 +103,7 @@ upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할
[reset 플레이북](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.
{{< caution >}}
{{< caution >}}
reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타겟으로 삼지 않도록 해야 한다!
{{< /caution >}}
@ -116,4 +116,3 @@ reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.

4
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -43,7 +43,7 @@ weight: 65
지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다.
{{< /note >}}
{{< note >}}
모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다.
{{< /note >}}
{{< note >}}
윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다.
@ -527,7 +527,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다.
이 문제는 `hostname-override` 파라미터가 [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
이 문제는 `hostname-override` 파라미터가 [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.
```powershell
C:\k\kube-proxy.exe --hostname-override=$(hostname)

6
content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
View File

@ -30,7 +30,7 @@ card:
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
[마이너 버전 하나 차이 이내](/docs/setup/release/version-skew-policy/#kubectl)여야
[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야
한다.
@ -383,7 +383,3 @@ export KUBECONFIG=$KUBECONFIG_SAVED
* [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)

30
content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
View File

@ -125,6 +125,7 @@ min-kubernetes-server-version: v1.10
1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
```shell
# redis-master-765d459796-258hz 를 파드 이름으로 변경한다.
kubectl port-forward redis-master-765d459796-258hz 7000:6379
@ -157,10 +158,16 @@ min-kubernetes-server-version: v1.10
위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
```
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
Forwarding from 127.0.0.1:7000 -> 6379
Forwarding from [::1]:7000 -> 6379
```
{{< note >}}
`kubectl port-forward` 는 프롬프트를 리턴하지 않으므로, 이 연습을 계속하려면 다른 터미널을 열어야 한다.
{{< /note >}}
2. Redis 커맨드라인 인터페이스를 실행한다.
```shell
@ -179,7 +186,23 @@ min-kubernetes-server-version: v1.10
PONG
```
### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port}
만약 특정 로컬 포트가 필요하지 않다면, `kubectl` 이 로컬 포트를 선택 및 할당하게 하여,
조금 더 단순한 문법으로 로컬 포트 충돌 관리를 위한
부담을 줄일 수 있다.
```shell
kubectl port-forward deployment/redis-master :6379
```
`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는
다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다.
```
Forwarding from 127.0.0.1:62162 -> 6379
Forwarding from [::1]:62162 -> 6379
```
<!-- discussion -->
@ -193,8 +216,7 @@ min-kubernetes-server-version: v1.10
{{< note >}}
`kubectl port-forward` 는 TCP 포트에서만 구현된다.
UDP 프로토콜에 대한 지원은
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)
에서 추적되고 있다.
[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)에서 추적되고 있다.
{{< /note >}}

2
content/ko/docs/tasks/administer-cluster/access-cluster-api.md
View File

@ -148,7 +148,7 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
없다. [쿠버네티스 API에 대한 접근 제어](/docs/concepts/security/controlling-access)은
없다. [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은
클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
고 가용성 지원과 충돌할 수 있다.

18
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -1,4 +1,6 @@
---
title: kubeadm 클러스터 업그레이드
content_type: task
weight: 20
@ -229,6 +231,14 @@ sudo systemctl restart kubelet
{{% /tab %}}
{{< /tabs >}}
### "kubeadm upgrade" 호출
- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
```shell
sudo kubeadm upgrade node
```
### 노드 드레인
- 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
@ -238,14 +248,6 @@ sudo systemctl restart kubelet
kubectl drain <node-to-drain> --ignore-daemonsets
```
### kubeadm 업그레이드 호출
- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
```shell
sudo kubeadm upgrade node
```
### kubelet과 kubectl 업그레이드
- kubelet 및 kubectl을 업그레이드한다.

4
content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
View File

@ -1,4 +1,6 @@
---
title: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
content_type: task
---
@ -48,7 +50,7 @@ kubectl describe pods ${POD_NAME}
* 클러스터에 노드를 더 추가하기.
* pending 상태인 파드를 위한 공간을 확보하기 위해
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
[불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
* 파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든
노드가 `cpu:1` 의 용량을 가지고 있을 경우, `cpu: 1.1` 을 요청하는 파드는

2
content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
View File

@ -6,7 +6,7 @@ content_type: task
<!-- overview -->
이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
이 가이드는 [kubectl](/ko/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는
플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다.

21
content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
View File

@ -1,4 +1,6 @@
---
title: HugePages 관리
content_type: task
description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다.
@ -102,17 +104,18 @@ spec:
- Huge page 요청(requests)은 제한(limits)과 같아야 한다. 제한이 지정되었지만, 요청은 지정되지 않은 경우
이것이 기본값이다.
- Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로 cgroup 샌드박스에 대한 제한이 있다.
- Huge page는 컨테이너 범위에서 격리되므로, 각 컨테이너에는 컨테이너 사양에서 요청한대로
cgroup 샌드박스에 대한 제한이 있다.
- Huge page가 지원하는 EmptyDir 볼륨은 파드 요청보다 더 많은 huge page 메모리를
사용하지 말아야 한다.
- `shmget()` 의 `SHM_HUGETLB` 를 통해 huge page를 사용하는 애플리케이션은
`proc/sys/vm/hugetlb_shm_group` 과 일치하는 보충 그룹(supplemental group)으로 실행해야 한다.
- 네임스페이스에서의 huge page 사용은 `hugepages-<size>` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다. {{<
glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
glossary_tooltip text="kube-apiserver"
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
`HugePageStorageMediumSize` [기능
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 비활성화할 수 있다.
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
{{<glossary_tooltip text="kubelet" term_id="kubelet" >}} 및
{{<glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
(`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
사용하여 비활성화할 수 있다.

11
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -47,8 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다.
### 리소스 생성
컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
컨피그 맵과 시크릿은 파드와 같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다.
#### configMapGenerator
@ -591,7 +590,7 @@ spec:
containers:
- name: my-nginx
image: nginx
command: ["start", "--host", "\$(MY_SERVICE_NAME)"]
command: ["start", "--host", "$(MY_SERVICE_NAME)"]
EOF
# service.yaml 파일 생성
@ -655,10 +654,10 @@ spec:
## Base와 Overlay
Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는
Kustomize는 **base** 와 **overlay** 의 개념을 가지고 있다. **base** 는 `kustomization.yaml` 과 함께 사용되는 디렉터리다. 이는
사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
될 수 있다. **overlay** 는 `kustomization.yaml`이 있는 디렉터리로
다른 kustomization 디렉터리들을 `bases`로 참조한다. **base** 는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
이들의 위에 사용자 정의도 가질 수 있다.

4
content/ko/docs/tasks/tools/install-kubectl.md
View File

@ -9,7 +9,7 @@ card:
---
<!-- overview -->
쿠버네티스 커맨드 라인 도구인 [kubectl](/docs/reference/kubectl/kubectl/)을 사용하면,
쿠버네티스 커맨드 라인 도구인 [kubectl](/ko/docs/reference/kubectl/kubectl/)을 사용하면,
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며
로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는,
@ -526,4 +526,4 @@ compinit
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
* [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
* [kubectl 레퍼런스 문서](/ko/docs/reference/kubectl/kubectl/) 읽기

2
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -22,7 +22,7 @@ weight: 10
* [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/)
* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
* [kubectl](/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 커맨드 라인 도구
{{< note >}}
이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록

2
content/ko/docs/tutorials/stateful-application/zookeeper.md
View File

@ -23,7 +23,7 @@ weight: 40
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
- [kubectl CLI](/docs/reference/kubectl/kubectl/)
- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/)
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.

149
content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
View File

@ -9,78 +9,73 @@ weight: 10
이 페이지에서는 외부 IP 주소를 노출하는
쿠버네티스 서비스 오브젝트를 생성하는 방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
* Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여
쿠버네티스 클러스터를 생성한다.
이 튜토리얼은 [외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
클라우드 공급자가 필요하다.
쿠버네티스 클러스터를 생성한다. 이 튜토리얼은
[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
클라우드 공급자가 필요하다.
* `kubectl`이 쿠버네티스 API 서버와 통신하도록 설정한다.
자세한 내용은 클라우드 공급자의 설명을 참고한다.
자세한 내용은 클라우드 공급자의 설명을 참고한다.
## {{% heading "objectives" %}}
* Hello World 애플리케이션을 다섯 개의 인스턴스로 실행한다.
* 외부 IP 주소를 노출하는 서비스를 생성한다.
* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다.
<!-- lessoncontent -->
## 다섯 개의 파드에서 실행되는 애플리케이션에 대한 서비스 만들기
1. 클러스터에서 Hello World 애플리케이션을 실행한다.
{{< codenew file="service/load-balancer-example.yaml" >}}
{{< codenew file="service/load-balancer-example.yaml" >}}
```shell
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
```
위의 명령어는
{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
오브젝트와 관련된
{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
오브젝트를 생성한다. 레플리카셋은 다섯 개의
{{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며,
각 파드는 Hello World 애플리케이션을 실행한다.
```shell
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
```
위의 명령어는
{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
오브젝트와 관련된
{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
오브젝트를 생성한다. 레플리카셋은 다섯 개의
{{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며,
각 파드는 Hello World 애플리케이션을 실행한다.
1. 디플로이먼트에 대한 정보를 확인한다.
kubectl get deployments hello-world
kubectl describe deployments hello-world
```shell
kubectl get deployments hello-world
kubectl describe deployments hello-world
```
1. 레플리카셋 오브젝트에 대한 정보를 확인한다.
kubectl get replicasets
kubectl describe replicasets
```shell
kubectl get replicasets
kubectl describe replicasets
```
1. 디플로이먼트를 외부로 노출시키는 서비스 오브젝트를 생성한다.
kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
```shell
kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
```
1. 서비스에 대한 정보를 확인한다.
kubectl get services my-service
```shell
kubectl get services my-service
```
결과는 아래와 같은 형태로 나타난다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
```console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
```
{{< note >}}
@ -96,23 +91,27 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
1. 서비스에 대한 자세한 정보를 확인한다.
kubectl describe services my-service
```shell
kubectl describe services my-service
```
결과는 아래와 같은 형태로 나타난다.
출력 결과는 다음과 유사하다.
Name: my-service
Namespace: default
Labels: app.kubernetes.io/name=load-balancer-example
Annotations: <none>
Selector: app.kubernetes.io/name=load-balancer-example
Type: LoadBalancer
IP: 10.3.245.137
LoadBalancer Ingress: 104.198.205.71
Port: <unset> 8080/TCP
NodePort: <unset> 32377/TCP
Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
Session Affinity: None
Events: <none>
```console
Name: my-service
Namespace: default
Labels: app.kubernetes.io/name=load-balancer-example
Annotations: <none>
Selector: app.kubernetes.io/name=load-balancer-example
Type: LoadBalancer
IP: 10.3.245.137
LoadBalancer Ingress: 104.198.205.71
Port: <unset> 8080/TCP
NodePort: <unset> 32377/TCP
Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
Session Affinity: None
Events: <none>
```
서비스에 의해 노출된 외부 IP 주소 (`LoadBalancer Ingress`)를 기억해두자.
예시에서 외부 IP 주소는 104.198.205.71이다.
@ -124,21 +123,27 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
이 주소는 Hello World 애플리케이션을 실행 중인 파드의 내부 주소다.
해당 주소가 파드 주소인지 확인하려면, 아래 명령어를 입력하면 된다.
kubectl get pods --output=wide
```shell
kubectl get pods --output=wide
```
결과는 아래와 같은 형태로 나타난다.
출력 결과는 다음과 유사하다.
NAME ... IP NODE
hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a
hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc
```console
NAME ... IP NODE
hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a
hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc
```
1. Hello World 애플리케이션에 접근하기 위해
외부 IP 주소 (`LoadBalancer Ingress`)를 사용한다.
curl http://<external-ip>:<port>
```shell
curl http://<external-ip>:<port>
```
`<external-ip>`는 서비스의 외부 IP 주소 (`LoadBalancer Ingress`)를 의미하며,
`<port>`는 서비스 정보에서 `Port` 값을
@ -148,28 +153,26 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
성공적인 요청에 대한 응답으로 hello 메세지가 나타난다.
Hello Kubernetes!
```shell
Hello Kubernetes!
```
## {{% heading "cleanup" %}}
서비스를 삭제하려면, 아래의 명령어를 입력한다.
kubectl delete services my-service
```shell
kubectl delete services my-service
```
Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하려면,
아래의 명령어를 입력한다.
kubectl delete deployment hello-world
```shell
kubectl delete deployment hello-world
```
## {{% heading "whatsnext" %}}
[애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해
더 배워 본다.

58
content/zh/docs/concepts/architecture/nodes.md
View File

@ -170,7 +170,7 @@ When you want to create Node objects manually, set the kubelet flag `--register-
You can modify Node objects regardless of the setting of `--register-node`.
For example, you can set labels on an existing Node, or mark it unschedulable.
-->
#### 手动节点管理
### 手动节点管理
你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}
来创建和修改 Node 对象。
@ -283,6 +283,7 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
| `MemoryPressure` | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` |
| `PIDPressure` | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
{{< /table >}}
-->
{{< table caption = "节点状况及每种状况适用场景的描述" >}}
| 节点状况 | 描述 |
@ -292,6 +293,7 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` |
| `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` |
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
{{< /table >}}
<!--
If you use command-line tools to print details of a cordoned Node, the Condition includes
@ -455,7 +457,7 @@ of the node heartbeats as the cluster scales.
Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。
心跳有两种形式：`NodeStatus` 和 [`Lease` 对象]
(/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。
(/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。
每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}}
中都有一个与之关联的 `Lease` 对象。
`Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。
@ -619,6 +621,58 @@ for more information.
参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
了解详细信息。
<!--
## Graceful Node Shutdown {#graceful-node-shutdown}
-->
## 节点体面关闭 {#graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
<!--
If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node.
Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.
-->
如果你启用了 `GracefulNodeShutdown` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
那么 kubelet 尝试检测节点的系统关闭事件并终止在节点上运行的 Pod。
在节点终止期间，kubelet 保证 Pod 遵从常规的 [Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
<!--
When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases:
-->
当启用了 `GracefulNodeShutdown` 特性门控时，
kubelet 使用 [systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)
在给定的期限内延迟节点关闭。在关闭过程中，kubelet 分两个阶段终止 Pod：
<!--
1. Terminate regular pods running on the node.
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
-->
1. 终止在节点上运行的常规 Pod。
2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
<!--
Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
* `ShutdownGracePeriod`:
* Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
* `ShutdownGracePeriodCriticalPods`:
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This should be less than `ShutdownGracePeriod`.
-->
节点体面关闭的特性对应两个 [`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项：
* `ShutdownGracePeriod`：
* 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod 还是
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
* `ShutdownGracePeriodCriticalPods`：
* 在节点关闭期间指定用于终止
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
的持续时间。该值应小于 `ShutdownGracePeriod`。
<!--
For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
-->
例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`，则 kubelet 将延迟 30 秒关闭节点。
在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，而保留最后 10 秒用于终止
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
## {{% heading "whatsnext" %}}
<!--

Some files were not shown because too many files have changed in this diff Show More