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

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

This commit is contained in:
Nate W 2022-04-07 10:41:49 -07:00
parent a8b46072c3 d8dfd81d0c
commit d1bce4cb0d
148 changed files with 3268 additions and 1461 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
content/en/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md Normal file
View File

@ -0,0 +1,133 @@
---
layout: blog
title: "Kubernetes Removals and Deprecations In 1.24"
date: 2022-04-07
slug: upcoming-changes-in-kubernetes-1-24
---
**Author**: Mickey Boxell (Oracle)
As Kubernetes evolves, features and APIs are regularly revisited and removed. New features may offer
an alternative or improved approach to solving existing problems, motivating the team to remove the
old approach.
We want to make sure you are aware of the changes coming in the Kubernetes 1.24 release. The release will
**deprecate** several (beta) APIs in favor of stable versions of the same APIs. The major change coming
in the Kubernetes 1.24 release is the
[removal of Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim).
This is discussed below and will be explored in more depth at release time. For an early look at the
changes coming in Kubernetes 1.24, take a look at the in-progress
[CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md).
## A note about Dockershim
It's safe to say that the removal receiving the most attention with the release of Kubernetes 1.24
is Dockershim. Dockershim was deprecated in v1.20. As noted in the [Kubernetes 1.20 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation):
"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet
uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance
issues in the Kubernetes community." With the upcoming release of Kubernetes 1.24, the Dockershim will
finally be removed.
In the article [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/),
the authors succinctly captured the change's impact and encouraged users to remain calm:
> Docker as an underlying runtime is being deprecated in favor of runtimes that use the
> Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images
> will continue to work in your cluster with all runtimes, as they always have.
Several guides have been created with helpful information about migrating from dockershim
to container runtimes that are directly compatible with Kubernetes. You can find them on the
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
page in the Kubernetes documentation.
For more information about why Kubernetes is moving away from dockershim, check out the aptly
named: [Kubernetes is Moving on From Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)
and the [updated dockershim removal FAQ](/blog/2022/02/17/dockershim-faq/).
Take a look at the [Is Your Cluster Ready for v1.24?](/blog/2022/03/31/ready-for-dockershim-removal/) post to learn about how to ensure your cluster continues to work after upgrading from v1.23 to v1.24.
## The Kubernetes API removal and deprecation process
Kubernetes contains a large number of components that evolve over time. In some cases, this
evolution results in APIs, flags, or entire features, being removed. To prevent users from facing
breaking changes, Kubernetes contributors adopted a feature [deprecation policy](/docs/reference/using-api/deprecation-policy/).
This policy ensures that stable APIs may only be deprecated when a newer stable version of that
same API is available and that APIs have a minimum lifetime as indicated by the following stability levels:
* Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes.
* Beta or pre-release API versions must be supported for 3 releases after deprecation.
* Alpha or experimental API versions may be removed in any release without prior deprecation notice.
Removals follow the same deprecation policy regardless of whether an API is removed due to a beta feature
graduating to stable or because that API was not proven to be successful. Kubernetes will continue to make
sure migration options are documented whenever APIs are removed.
**Deprecated** APIs are those that have been marked for removal in a future Kubernetes release. **Removed**
APIs are those that are no longer available for use in current, supported Kubernetes versions after having
been deprecated. These removals have been superseded by newer, stable/generally available (GA) APIs.
## API removals, deprecations, and other changes for Kubernetes 1.24
* [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information.
* [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=).
* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations) for more information.
* [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/).
* [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information.
* [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint).
* [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information.
## What to do
### Dockershim removal
As stated earlier, there are several guides about
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
You can start with [Finding what container runtime are on your nodes](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
If your nodes are using dockershim, there are other possible Docker Engine dependencies such as
Pods or third-party tools executing Docker commands or private registries in the Docker configuration file. You can follow the
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) guide to review possible
Docker Engine dependencies. Before upgrading to v1.24, you decide to either remain using Docker Engine and
[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) or migrate to a CRI-compatible runtime. Here's a guide to
[change the container runtime on a node from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
### `kubectl convert`
The [`kubectl convert`](/docs/tasks/tools/included/kubectl-convert-overview/) plugin for `kubectl`
can be helpful to address migrating off deprecated APIs. The plugin facilitates the conversion of
manifests between different API versions, for example, from a deprecated to a non-deprecated API
version. More general information about the API migration process can be found in the [Deprecated API Migration Guide](/docs/reference/using-api/deprecation-guide/).
Follow the [install `kubectl convert` plugin](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin)
documentation to download and install the `kubectl-convert` binary.
### Looking ahead
The Kubernetes 1.25 and 1.26 releases planned for later this year will stop serving beta versions
of several currently stable Kubernetes APIs. The v1.25 release will also remove PodSecurityPolicy,
which was deprecated with Kubernetes 1.21 and will not graduate to stable. See [PodSecurityPolicy
Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) for more information.
The official [list of API removals planned for Kubernetes 1.25](/docs/reference/using-api/deprecation-guide/#v1-25) is:
* The beta CronJob API (batch/v1beta1)
* The beta EndpointSlice API (discovery.k8s.io/v1beta1)
* The beta Event API (events.k8s.io/v1beta1)
* The beta HorizontalPodAutoscaler API (autoscaling/v2beta1)
* The beta PodDisruptionBudget API (policy/v1beta1)
* The beta PodSecurityPolicy API (policy/v1beta1)
* The beta RuntimeClass API (node.k8s.io/v1beta1)
The official [list of API removals planned for Kubernetes 1.26](/docs/reference/using-api/deprecation-guide/#v1-26) is:
* The beta FlowSchema and PriorityLevelConfiguration APIs (flowcontrol.apiserver.k8s.io/v1beta1)
* The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
### Want to know more?
Deprecations are announced in the Kubernetes release notes. You can see the announcements of pending deprecations in the release notes for:
* [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation)
* [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation)
* [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation)
* We will formally announce the deprecations that come with [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) as part of the CHANGELOG for that release.
For information on the process of deprecation and removal, check out the official Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) document.

3
content/en/docs/concepts/architecture/nodes.md
View File

@ -539,6 +539,9 @@ Using this feature, requires enabling the
config's `ShutdownGracePeriodByPodPriority` to the desired configuration
containing the pod priority class values and their respective shutdown periods.
Metrics `graceful_shutdown_start_time_seconds` and `graceful_shutdown_end_time_seconds`
are emitted under the kubelet subsystem to monitor node shutdowns.
## Swap memory management {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}

4
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -124,8 +124,8 @@ For example, consider the following Pod spec:
In this example, the following rules apply:
* The node *must* have a label with the key `kubernetes.io/e2e-az-name` and
the value is either `e2e-az1` or `e2e-az2`.
* The node *must* have a label with the key `kubernetes.io/os` and
the value `linux`.
* The node *preferably* has a label with the key `another-node-label-key` and
the value `another-node-label-value`.

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

@ -25,7 +25,7 @@ and can load-balance across them.
## Motivation
Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed
to match the state of your cluster. Pods are nonpermanent resources.
to match the desired state of your cluster. Pods are nonpermanent resources.
If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app,
it can create and destroy Pods dynamically.

14
content/en/docs/concepts/storage/volumes.md
View File

@ -151,6 +151,13 @@ Storage Interface (CSI) Driver. In order to use this feature, the
[Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
must be installed on the cluster and the `CSIMigration` feature must be enabled.
#### azureDisk CSI migration complete
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
To disable the `azureDisk` storage plugin from being loaded by the controller manager
and the kubelet, set the `InTreePluginAzureDiskUnregister` flag to `true`.
### azureFile {#azurefile}
The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0)
@ -172,6 +179,13 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFi
Azure File CSI driver does not support using same volume with different fsgroups. If
`CSIMigrationAzureFile` is enabled, using same volume with different fsgroups won't be supported at all.
#### azureFile CSI migration complete
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
To disable the `azureFile` storage plugin from being loaded by the controller manager
and the kubelet, set the `InTreePluginAzureFileUnregister` flag to `true`.
### cephfs
A `cephfs` volume allows an existing CephFS volume to be

2
content/en/docs/concepts/workloads/controllers/replicaset.md
View File

@ -223,8 +223,6 @@ In this manner, a ReplicaSet can own a non-homogenous set of Pods
As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields.
For ReplicaSets, the `kind` is always a ReplicaSet.
In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
Refer to the first lines of the `frontend.yaml` example for guidance.
The name of a ReplicaSet object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

4
content/en/docs/concepts/workloads/controllers/statefulset.md
View File

@ -115,7 +115,7 @@ The name of a StatefulSet object must be a valid
### Pod Selector
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
### Volume Claim Templates
@ -226,7 +226,7 @@ is completely shutdown, but prior to web-1's termination, web-1 would not be ter
until web-0 is Running and Ready.
### Pod Management Policies
In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
StatefulSet allows you to relax its ordering guarantees while
preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field.
#### OrderedReady Pod Management

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

@ -300,7 +300,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
@ -356,7 +357,8 @@ apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []

7
content/en/docs/contribute/localization.md
View File

@ -125,11 +125,14 @@ Add a configuration block for the new language to `config.toml`, under the exist
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
languageName = "Deutsch (German)"
languageNameLatinScript = "German"
contentDir = "content/de"
weight = 3
weight = 8
```
The value for `languageName` will be listed in language selection bar. Assign "language name in native script (language name in latin script)" to `languageName`, for example, `languageName = "한국어 (Korean)"`. `languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`, for example, `languageNameLatinScript ="Korean"`.
When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value.
For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".

1
content/en/docs/reference/glossary/pod-security-policy.md
View File

@ -17,3 +17,4 @@ tags:
A cluster-level resource that controls security sensitive aspects of the Pod specification. The `PodSecurityPolicy` objects define a set of conditions that a Pod must run with in order to be accepted into the system, as well as defaults for the related fields. Pod Security Policy control is implemented as an optional admission controller.
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. We recommend migrating to [Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.

59
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md
View File

@ -4,20 +4,28 @@ weight: 8
content_type: task
---
This task outlines the steps needed to update your container runtime to containerd from Docker. It is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an example scenario for migrating from dockershim to containerd and alternative container runtimes can be picked from this [page](https://kubernetes.io/docs/setup/production-environment/container-runtimes/).
This task outlines the steps needed to update your container runtime to containerd from Docker. It
is applicable for cluster operators running Kubernetes 1.23 or earlier. Also this covers an
example scenario for migrating from dockershim to containerd and alternative container runtimes
can be picked from this [page](/docs/setup/production-environment/container-runtimes/).
## {{% heading "prerequisites" %}}
{{% thirdparty-content %}}
Install containerd. For more information see, [containerd's installation documentation](https://containerd.io/docs/getting-started/) and for specific prerequisite follow [this](/docs/setup/production-environment/container-runtimes/#containerd).
Install containerd. For more information see
[containerd's installation documentation](https://containerd.io/docs/getting-started/)
and for specific prerequisite follow
[the containerd guide](/docs/setup/production-environment/container-runtimes/#containerd).
## Drain the node
```
# replace <node-to-drain> with the name of your node you are draining
```shell
kubectl drain <node-to-drain> --ignore-daemonsets
```
Replace `<node-to-drain>` with the name of your node you are draining.
## Stop the Docker daemon
```shell
@ -27,32 +35,33 @@ systemctl disable docker.service --now
## Install Containerd
This [page](/docs/setup/production-environment/container-runtimes/#containerd) contains detailed steps to install containerd.
Follow the [guide](/docs/setup/production-environment/container-runtimes/#containerd)
for detailed steps to install containerd.
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
1. Install the `containerd.io` package from the official Docker repositories.
Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
Instructions for setting up the Docker repository for your respective Linux distribution and
installing the `containerd.io` package can be found at
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
2. Configure containerd:
1. Configure containerd:
```shell
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
3. Restart containerd:
1. Restart containerd:
```shell
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and then run the following commands:
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and
then run the following commands:
1. Download containerd:
@ -89,24 +98,25 @@ Start a Powershell session, set `$Version` to the desired version (ex: `$Version
## Configure the kubelet to use containerd as its container runtime
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags. `--container-runtime=remote` and `--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`
Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtime to the flags.
`--container-runtime=remote` and
`--container-runtime-endpoint=unix:///run/containerd/containerd.sock"`.
For users using kubeadm should consider the following:
Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
an annotation in the Node object for that host. To change it you can execute the following command
on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
The `kubeadm` tool stores the CRI socket for each host as an annotation in the Node object for that host.
To change it you must do the following:
Execute `kubectl edit no <NODE-NAME>` on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
```shell
kubectl edit no <node-name>
```
This will start a text editor where you can edit the Node object.
To choose a text editor you can set the `KUBE_EDITOR` environment variable.
- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
Note that new CRI socket paths must be prefixed with `unix://` ideally.
Note that new CRI socket paths must be prefixed with `unix://` ideally.
- Save the changes in the text editor, which will update the Node object.
@ -124,7 +134,7 @@ Run `kubectl get nodes -o wide` and containerd appears as the runtime for the no
{{% thirdparty-content %}}
Finally if everything goes well remove docker
Finally if everything goes well, remove Docker.
{{< tabs name="tab-remove-docker-enigine" >}}
{{% tab name="CentOS" %}}
@ -151,4 +161,5 @@ sudo dnf remove docker-ce docker-ce-cli
sudo apt-get purge docker-ce docker-ce-cli
```
{{% /tab %}}
{{< /tabs >}}
{{< /tabs >}}

121
content/en/docs/tasks/administer-cluster/nodelocaldns.md
View File

@ -8,36 +8,49 @@ content_type: task
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
This page provides an overview of NodeLocal DNSCache feature in Kubernetes.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## Introduction
NodeLocal DNSCache improves Cluster DNS performance by running a dns caching agent on cluster nodes as a DaemonSet. In today's architecture, Pods in ClusterFirst DNS mode reach out to a kube-dns serviceIP for DNS queries. This is translated to a kube-dns/CoreDNS endpoint via iptables rules added by kube-proxy. With this new architecture, Pods will reach out to the dns caching agent running on the same node, thereby avoiding iptables DNAT rules and connection tracking. The local caching agent will query kube-dns service for cache misses of cluster hostnames(cluster.local suffix by default).
NodeLocal DNSCache improves Cluster DNS performance by running a DNS caching agent
on cluster nodes as a DaemonSet. In today's architecture, Pods in 'ClusterFirst' DNS mode
reach out to a kube-dns `serviceIP` for DNS queries. This is translated to a
kube-dns/CoreDNS endpoint via iptables rules added by kube-proxy.
With this new architecture, Pods will reach out to the DNS caching agent
running on the same node, thereby avoiding iptables DNAT rules and connection tracking.
The local caching agent will query kube-dns service for cache misses of cluster
hostnames ("`cluster.local`" suffix by default).
## Motivation
* With the current DNS architecture, it is possible that Pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns/CoreDNS instance.
Having a local cache will help improve the latency in such scenarios.
* With the current DNS architecture, it is possible that Pods with the highest DNS QPS
have to reach out to a different node, if there is no local kube-dns/CoreDNS instance.
Having a local cache will help improve the latency in such scenarios.
* Skipping iptables DNAT and connection tracking will help reduce [conntrack races](https://github.com/kubernetes/kubernetes/issues/56903) and avoid UDP DNS entries filling up conntrack table.
* Skipping iptables DNAT and connection tracking will help reduce
[conntrack races](https://github.com/kubernetes/kubernetes/issues/56903)
and avoid UDP DNS entries filling up conntrack table.
* Connections from local caching agent to kube-dns service can be upgraded to TCP. TCP conntrack entries will be removed on connection close in contrast with UDP entries that have to timeout ([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` is 30 seconds)
* Connections from local caching agent to kube-dns service can be upgraded to TCP.
TCP conntrack entries will be removed on connection close in contrast with
UDP entries that have to timeout
([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt)
`nf_conntrack_udp_timeout` is 30 seconds)
* Upgrading DNS queries from UDP to TCP would reduce tail latency attributed to dropped UDP packets and DNS timeouts usually up to 30s (3 retries + 10s timeout). Since the nodelocal cache listens for UDP DNS queries, applications don't need to be changed.
* Upgrading DNS queries from UDP to TCP would reduce tail latency attributed to
dropped UDP packets and DNS timeouts usually up to 30s (3 retries + 10s timeout).
Since the nodelocal cache listens for UDP DNS queries, applications don't need to be changed.
* Metrics & visibility into dns requests at a node level.
* Metrics & visibility into DNS requests at a node level.
* Negative caching can be re-enabled, thereby reducing number of queries to kube-dns service.
@ -49,48 +62,75 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." class="diagram-medium" >}}
## Configuration
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any address that can be guaranteed to not collide with any existing IP in your cluster. It's recommended to use an address with a local scope, per example, from the link-local range 169.254.0.0/16 for IPv4 or from the Unique Local Address range in IPv6 fd00::/8.
{{< note >}}
The local listen IP address for NodeLocal DNSCache can be any address that
can be guaranteed to not collide with any existing IP in your cluster.
It's recommended to use an address with a local scope, per example,
from the 'link-local' range '169.254.0.0/16' for IPv4 or from the
'Unique Local Address' range in IPv6 'fd00::/8'.
{{< /note >}}
This feature can be enabled using the following steps:
* Prepare a manifest similar to the sample [`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml) and save it as `nodelocaldns.yaml.`
* If using IPv6, the CoreDNS configuration file need to enclose all the IPv6 addresses into square brackets if used in IP:Port format.
If you are using the sample manifest from the previous point, this will require to modify [the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70) like this `health [__PILLAR__LOCAL__DNS__]:8080`
* Prepare a manifest similar to the sample
[`nodelocaldns.yaml`](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml)
and save it as `nodelocaldns.yaml.`
* If using IPv6, the CoreDNS configuration file need to enclose all the IPv6 addresses
into square brackets if used in 'IP:Port' format.
If you are using the sample manifest from the previous point, this will require to modify
[the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70)
like this: "`health [__PILLAR__LOCAL__DNS__]:8080`"
* Substitute the variables in the manifest with the right values:
* kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
```shell
kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
domain=<cluster-domain>
localdns=<node-local-address>
```
* domain=`<cluster-domain>`
`<cluster-domain>` is "`cluster.local`" by default. `<node-local-address>` is the
local listen IP address chosen for NodeLocal DNSCache.
* localdns=`<node-local-address>`
* If kube-proxy is running in IPTABLES mode:
`<cluster-domain>` is "cluster.local" by default. `<node-local-address>` is the local listen IP address chosen for NodeLocal DNSCache.
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
```
* If kube-proxy is running in IPTABLES mode:
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
```
`__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
In this mode, node-local-dns pods listen on both the kube-dns service IP as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
`__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by
the `node-local-dns` pods.
In this mode, the `node-local-dns` pods listen on both the kube-dns service IP
as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
* If kube-proxy is running in IPVS mode:
``` bash
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
```
In this mode, node-local-dns pods listen only on `<node-local-address>`. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
`__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
In this mode, the `node-local-dns` pods listen only on `<node-local-address>`.
The `node-local-dns` interface cannot bind the kube-dns cluster IP since the
interface used for IPVS loadbalancing already uses this address.
`__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.
* Run `kubectl create -f nodelocaldns.yaml`
* If using kube-proxy in IPVS mode, `--cluster-dns` flag to kubelet needs to be modified to use `<node-local-address>` that NodeLocal DNSCache is listening on.
Otherwise, there is no need to modify the value of the `--cluster-dns` flag, since NodeLocal DNSCache listens on both the kube-dns service IP as well as `<node-local-address>`.
Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis.
* If using kube-proxy in IPVS mode, `--cluster-dns` flag to kubelet needs to be modified
to use `<node-local-address>` that NodeLocal DNSCache is listening on.
Otherwise, there is no need to modify the value of the `--cluster-dns` flag,
since NodeLocal DNSCache listens on both the kube-dns service IP as well as
`<node-local-address>`.
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>` . You should also revert any changes you made to the kubelet configuration.
Once enabled, the `node-local-dns` Pods will run in the `kube-system` namespace
on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns)
in cache mode, so all CoreDNS metrics exposed by the different plugins will
be available on a per-node basis.
You can disable this feature by removing the DaemonSet, using `kubectl delete -f <manifest>`.
You should also revert any changes you made to the kubelet configuration.
## StubDomains and Upstream server Configuration
@ -103,7 +143,9 @@ In those cases, the `kube-dns` ConfigMap can be updated.
## Setting memory limits
node-local-dns pods use memory for storing cache entries and processing queries. Since they do not watch Kubernetes objects, the cluster size or the number of Services/Endpoints do not directly affect memory usage. Memory usage is influenced by the DNS query pattern.
The `node-local-dns` Pods use memory for storing cache entries and processing queries.
Since they do not watch Kubernetes objects, the cluster size or the number of Services/Endpoints
do not directly affect memory usage. Memory usage is influenced by the DNS query pattern.
From [CoreDNS docs](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md),
> The default cache size is 10000 entries, which uses about 30 MB when completely filled.
@ -114,13 +156,13 @@ The number of concurrent queries is linked to the memory demand, because each ex
goroutine used for handling a query requires an amount of memory. You can set an upper limit
using the `max_concurrent` option in the forward plugin.
If a node-local-dns pod attempts to use more memory than is available (because of total system
If a `node-local-dns` Pod attempts to use more memory than is available (because of total system
resources, or because of a configured
[resource limit](/docs/concepts/configuration/manage-resources-containers/)), the operating system
may shut down that pod's container.
If this happens, the container that is terminated (“OOMKilled”) does not clean up the custom
packet filtering rules that it previously added during startup.
The node-local-dns container should get restarted (since managed as part of a DaemonSet), but this
The `node-local-dns` container should get restarted (since managed as part of a DaemonSet), but this
will lead to a brief DNS downtime each time that the container fails: the packet filtering rules direct
DNS queries to a local Pod that is unhealthy.
@ -128,3 +170,4 @@ You can determine a suitable memory limit by running node-local-dns pods without
measuring the peak usage. You can also set up and use a
[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)
in _recommender mode_, and then check its recommendations.

12
content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
View File

@ -2,7 +2,7 @@
reviewers:
- fgrzadkowski
- piosz
title: Resource metrics pipeline
title: Resource metrics pipeline
content_type: concept
---
@ -77,7 +77,7 @@ The architecture components, from right to left in the figure, consist of the fo
* [Metrics API](#metrics-api): Kubernetes API supporting access to CPU and memory used for
workload autoscaling. To make this work in your cluster, you need an API extension server that
provides the Metrics API.
{{< note >}}
cAdvisor supports reading metrics from cgroups, which works with typical container runtimes on Linux.
If you use a container runtime that uses another resource isolation mechanism, for example
@ -85,14 +85,15 @@ The architecture components, from right to left in the figure, consist of the fo
[CRI Container Metrics](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md)
in order for metrics to be available to the kubelet.
{{< /note >}}
<!-- body -->
## Metrics API
{{< feature-state for_k8s_version="1.8" state="beta" >}}
The metrics-server implements the Metrics API. This API allows you to access CPU and memory usage
for the nodes and pods in your cluster. Its primary role is to feed resource usage metrics to K8s
autoscaler components.
autoscaler components.
Here is an example of the Metrics API request for a `minikube` node piped through `jq` for easier
reading:
@ -201,7 +202,7 @@ Memory is reported as the working set, measured in bytes, at the instant the met
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under
memory pressure. However, calculation of the working set varies by host OS, and generally makes
heavy use of heuristics to produce an estimate.
heavy use of heuristics to produce an estimate.
The Kubernetes model for a container's working set expects that the container runtime counts
anonymous memory associated with the container in question. The working set metric typically also
@ -264,4 +265,3 @@ curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary
The summary API `/stats/summary` endpoint will be replaced by the `/metrics/resource` endpoint
beginning with metrics-server 0.6.x.
{{< /note >}}

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

@ -37,7 +37,7 @@ httpd running some PHP code.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} If you're running an older
release of Kubernetes, refer to the version of the documentation for that release (see
[available documentation versions](/docs/home/supported-doc-versions/).
[available documentation versions](/docs/home/supported-doc-versions/)).
To follow this walkthrough, you also need to use a cluster that has a
[Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme) deployed and configured.

2
content/ja/docs/concepts/cluster-administration/networking.md
View File

@ -115,7 +115,7 @@ addressing, and it can be used in combination with other CNI plugins.
### CNI-Genie from Huawei
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/ja/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.

7
content/ja/docs/concepts/extend-kubernetes/_index.md
View File

@ -19,14 +19,11 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
*設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
* [kubelet](/docs/admin/kubelet/)
* [kube-apiserver](/docs/admin/kube-apiserver/)
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
* [kube-scheduler](/docs/admin/kube-scheduler/)
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。

170
content/ja/docs/concepts/security/controlling-access.md Normal file
View File

@ -0,0 +1,170 @@
---
title: Kubernetes APIへのアクセスコントロール
content_type: concept
---
<!-- overview -->
このページではKubernetes APIへのアクセスコントロールの概要を説明します。
<!-- body -->
[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)には`kubectl`やクライアントライブラリ、あるいはRESTリクエストを用いてアクセスします。
APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。
リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。
![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg)
## トランスポート層のセキュリティ {#transport-security}
一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。
APIサーバーは証明書を提示します。
この証明書は、プライベート認証局(CA)を用いて署名することも、一般に認知されているCAと連携した公開鍵基盤に基づき署名することも可能です。
クラスターがプライベート認証局を使用している場合、接続を信頼し、傍受されていないと確信できるように、クライアント上の`~/.kube/config`に設定されたそのCA証明書のコピーが必要です。
クライアントは、この段階でTLSクライアント証明書を提示することができます。
## 認証 {#authentication}
TLSが確立されると、HTTPリクエストは認証のステップに移行します。
これは図中のステップ**1**に該当します。
クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。
Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/authentication/)で詳しく説明されています。
認証ステップへの入力はHTTPリクエスト全体ですが、通常はヘッダとクライアント証明書の両方、またはどちらかを調べます。
認証モジュールには、クライアント証明書、パスワード、プレーントークン、ブートストラップトークン、JSON Web Tokens(サービスアカウントに使用)などがあります。
複数の認証モジュールを指定することができ、その場合、1つの認証モジュールが成功するまで、それぞれを順番に試行します。
認証できない場合、HTTPステータスコード401で拒否されます。
そうでなければ、ユーザーは特定の`username`として認証され、そのユーザー名は後続のステップでの判断に使用できるようになります。
また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関があります。
Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。
## 認可 {#authorization}
リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。
これは図のステップ**2**に該当します。
リクエストには、リクエスト者のユーザー名、リクエストされたアクション、そのアクションによって影響を受けるオブジェクトを含める必要があります。
既存のポリシーで、ユーザーが要求されたアクションを完了するための権限を持っていると宣言されている場合、リクエストは承認されます。
例えば、Bobが以下のようなポリシーを持っている場合、彼は名前空間`projectCaribou`内のPodのみを読むことができます。
```json
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
```
Bobが次のようなリクエストをした場合、Bobは名前空間`projectCaribou`のオブジェクトを読むことが許可されているので、このリクエストは認可されます。
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
```
Bobが名前空間`projectCaribou`のオブジェクトに書き込み(`create`または`update`)のリクエストをした場合、承認は拒否されます。
また、もしBobが`projectFish`のような別の名前空間にあるオブジェクトを読み込む(`get`)リクエストをした場合も、承認は拒否されます。
Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセスコントロールシステムと対話するために、共通のREST属性を使用する必要があります。
これらのコントロールシステムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。
Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数の認可モジュールをサポートしています。
管理者はクラスターを作成する際に、APIサーバーで使用する認証モジュールを設定します。
複数の認可モジュールが設定されている場合、Kubernetesは各モジュールをチェックし、いずれかのモジュールがリクエストを認可した場合、リクエストを続行することができます。
すべてのモジュールがリクエストを拒否した場合、リクエストは拒否されます(HTTPステータスコード403)。
サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、[認可](/docs/reference/access-authn-authz/authorization/)を参照してください。
## アドミッションコントロール {#admission-control}
アドミッションコントロールモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。
認可モジュールが利用できる属性に加えて、アドミッションコントロールモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。
アドミッションコントローラーは、オブジェクトの作成、変更、削除、または接続(プロキシ)を行うリクエストに対して動作します。
アドミッションコントローラーは、単にオブジェクトを読み取るだけのリクエストには動作しません。
複数のアドミッションコントローラーが設定されている場合は、順番に呼び出されます。
これは図中のステップ**3**に該当します。
認証・認可モジュールとは異なり、いずれかのアドミッションコントローラーモジュールが拒否した場合、リクエストは即座に拒否されます。
オブジェクトを拒否するだけでなく、アドミッションコントローラーは、フィールドに複雑なデフォルトを設定することもできます。
利用可能なアドミッションコントロールモジュールは、[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)に記載されています。
リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ**4**に該当します)。
## 監査 {#auditing}
Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。
クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。
詳しくは[監査](/ja/docs/tasks/debug-application-cluster/audit/)をご覧ください。
## APIサーバーのIPとポート {#api-server-ports-and-ips}
これまでの説明は、APIサーバーのセキュアポートに送信されるリクエストに適用されます(典型的なケース)。
APIサーバーは、実際には2つのポートでサービスを提供することができます。
デフォルトでは、Kubernetes APIサーバーは2つのポートでHTTPを提供します。
1. `localhost`ポート:
- テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラー、コントローラーマネージャー)がAPIと通信するためのものです。
- TLSは使用しません。
- デフォルトポートは8080です。
- デフォルトのIPはlocalhostですが、`--insecure-bind-address`フラグで変更することができます。
- リクエストは認証と認可のモジュールを**バイパス**します。
- リクエストは、アドミッションコントロールモジュールによって処理されます。
- ホストにアクセスする必要があるため、保護されています。
2. “セキュアポート”:
- 可能な限りこちらを使用してください。
- TLSを使用します。証明書は`--tls-cert-file`フラグで、鍵は`--tls-private-key-file`フラグで設定します。
- デフォルトポートは6443です。`--secure-port`フラグで変更することができます。
- デフォルトのIPは、最初の非localhostのネットワークインターフェースです。`--bind-address`フラグで変更することができます。
- リクエストは、認証・認可モジュールによって処理されます。
- リクエストは、アドミッションコントロールモジュールによって処理されます。
- 認証・認可モジュールが実行されます。
## {{% heading "whatsnext" %}}
認証、認可、APIアクセスコントロールに関する詳しいドキュメントはこちらをご覧ください。
- [認証](/ja/docs/reference/access-authn-authz/authentication/)
- [ブートストラップトークンでの認証](/docs/reference/access-authn-authz/bootstrap-tokens/)
- [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)
- [動的アドミッションコントロール](/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [認可](/docs/reference/access-authn-authz/authorization/)
- [ロールに基づいたアクセスコントロール](/ja/docs/reference/access-authn-authz/rbac/)
- [属性に基づいたアクセスコントロール](/docs/reference/access-authn-authz/abac/)
- [Nodeの認可](/docs/reference/access-authn-authz/node/)
- [Webhookの認可](/docs/reference/access-authn-authz/webhook/)
- [証明書の署名要求](/docs/reference/access-authn-authz/certificate-signing-requests/)
- [CSRの承認](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)と[証明書の署名](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)を含む
- サービスアカウント
- [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
- [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
以下についても知ることができます。
- PodがAPIクレデンシャルを取得するために[Secrets](/ja/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)を使用する方法について。

2
content/ko/docs/concepts/architecture/cri.md
View File

@ -15,7 +15,7 @@ weight: 50
{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을
구동할 수 있다.
{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
{{< glossary_definition prepend="컨테이너 런타임 인터페이스(CRI)는" term_id="container-runtime-interface" length="all" >}}
<!-- body -->

172
content/ko/docs/concepts/architecture/garbage-collection.md Normal file
View File

@ -0,0 +1,172 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 50
---
<!-- overview -->
{{<glossary_definition term_id="garbage-collection" length="short">}}
다음과 같은 리소스를 정리한다:
* [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
* [소유자 참조가 없는 오브젝트](#owners-dependents)
* [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images)
* [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/#delete)
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) <!-- en 글에서부터 링크가 깨져있어 /docs를 따로 추가-->
* {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다:
* 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스
* [노드 리스(Lease) 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)
## 소유자(Owners)와 종속(dependents) {#owners-dependents}
쿠버네티스의 많은 오브젝트는 [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/)를 통해 서로 연결되어 있다.
소유자 참조(Owner references)는 컨트롤 플레인에게 어떤 오브젝트가 서로 종속적인지를 알려준다.
쿠버네티스는 소유자 참조를 사용하여 컨트롤 플레인과 다른 API 클라이언트에게 오브젝트를 삭제하기 전 관련 리소스를 정리하는 기회를 제공한다. 대부분의 경우, 쿠버네티스는 소유자 참조를 자동으로 관리한다.
소유권(Ownership)은 일부 리소스가 사용하는 [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)
메커니즘과는 다르다. 예를 들어,
`EndpointSlice` 오브젝트를 생성하는 {{<glossary_tooltip text="서비스" term_id="service">}}를
생각해보자. 서비스는 *레이블*을 사용해 컨트롤 플레인이
어떤 `EndpointSlice` 오브젝트가 해당 서비스에 의해 사용되는지 판단하는 데 도움을 준다. 레이블과 더불어,
서비스를 대신해 관리되는 각 `EndpointSlice` 오브젝트는
소유자 참조를 가진다. 소유자 참조는 쿠버네티스의 다른 부분이 제어하지 않는
오브젝트를 방해하는 것을 방지하는 데 도움을 준다.
{{< note >}}
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 오브젝트는 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 **반드시** 종속 오브젝트와 동일한 네임스페이스에 존재해야 한다.
그렇지 않다면, 소유자 참조는 없는 것으로 간주되어, 종속 오브젝트는
모든 소유자가 없는 것으로 확인되면 삭제될 수 있다.
클러스터 범위의 종속 오브젝트는 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서, 클러스터 범위의 종속 오브젝트가 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 간주되어 가비지 수집이 될 수 없다.
v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
또는 네임스페이스 종류를 참조하는 `ownerReference`가 있는 클러스터 범위의 종속 항목을 감지하면,
`OwnerRefInvalidNamespace`가 원인인 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject`가 보고된다.
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`
를 실행하여 이러한 종류의 이벤트를 확인할 수 있다.
{{< /note >}}
## 캐스케이딩(Cascading) 삭제 {#cascading-deletion}
쿠버네티스는 오브젝트를 삭제할 때 더 이상 소유자 참조가 없는지,
예를 들어 레플리카셋을 삭제할 때, 남겨진 파드가 없는지 확인하고 삭제한다.
오브젝트를 삭제할 때 쿠버네티스가 오브젝트의 종속 오브젝트들을 자동으로 삭제할 지 여부를 제어할 수 있다.
이 과정을 `캐스케이딩 삭제`라고 한다.
캐스케이딩 삭제에는 다음과 같은 두 가지 종류가 있다.
* 포그라운드 캐스케이딩 삭제(Foreground cascading deletion)
* 백그라운드 캐스케이딩 삭제(Background cascading deletion)
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
### 포그라운드 캐스케이딩 삭제 {#foreground-deletion}
포그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저
*삭제 중* 상태가 된다. 이 상태에서는 소유자 오브젝트에게 다음과 같은 일이
일어난다:
* 쿠버네티스 API 서버가 오브젝트의 `metadata.deletionTimestamp` 필드를
오브젝트가 삭제 표시된 시간으로 설정한다.
* 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로
설정한다.
* 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다.
소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다.
모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다.
이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다.
포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다.
더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
참고한다.
### 백그라운드 캐스케이딩 삭제 {#background-deletion}
백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고
백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다.
쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
더 자세한 내용은 [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를
참고한다.
### 분리된 종속 (Orphaned dependents)
쿠버네티스가 소유자 오브젝트를 삭제할 때, 남은 종속 오브젝트는 *분리된* 오브젝트라고 부른다.
기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다.
이 행동을 오버라이드하는 방법을 보려면,
다음 [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다.
## 사용되지 않는 컨테이너와 이미지 가비지 수집 {#containers-images}
{{<glossary_tooltip text="kubelet" term_id="kubelet">}}은
사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다
수행한다. 외부 가비지 수집 도구는 Kubelet 의 행동을 중단시키고
존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다.
사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면,
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 Kubelet 을 수정하거나
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 리소스 타입의
가비지 수집과 관련된 파라미터를 수정한다.
### 컨테이너 이미지 라이프사이클
쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
모든 이미지의 라이프사이클을 관리한다.
Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다.
* `HighThresholdPercent`
* `LowThresholdPercent`
`HighThresholdPercent` 값을 초과한 디스크 사용량은
마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는
가비지 수집을 트리거한다. Kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
이미지를 삭제한다.
### 컨테이너 이미지 가비지 수집 {#container-image-garbage-collection}
Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다:
* `MinAge`: Kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다.
* `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수.
`0`으로 세팅하여 비활성화할 수 있다.
* `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수
`0`으로 세팅하여 비활성화할 수 있다.
위 변수와 더불어, Kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다.
`MaxPerPodContainer`와 `MaxContainer`는
파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이
전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때,
서로 충돌이 발생할 수 있다.
이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고
가장 오래된 컨테이너들을 축출한다.
또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다.
{{<note>}}
Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
{{</note>}}
## 가비지 수집 구성하기 {#configuring-gc}
자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다.
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다:
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/docs/tasks/administer-cluster/use-cascading-deletion/)
* [완료된 잡 자동 정리하기](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
## {{% heading "whatsnext" %}}
* [쿠버네티스 오브젝트의 소유권](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자.
* 쿠버네티스 [finalizers](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
* 완료된 잡을 정리하는 [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자.

2
content/ko/docs/concepts/architecture/nodes.md
View File

@ -33,7 +33,7 @@ weight: 10
1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
노드 {{< glossary_tooltip text="오브젝트" term_id="object" >}} 또는 노드의 kubelet으로 자체 등록한 후
컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.

1
content/ko/docs/concepts/cluster-administration/addons.md
View File

@ -21,7 +21,6 @@ content_type: concept
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
* [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.

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

@ -1,109 +0,0 @@
---
title: kubelet 가비지(Garbage) 수집 설정하기
content_type: concept
weight: 70
---
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
가비지 수집은 사용되지 않는
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써
kubelet을 중단시킬 수도 있으므로 권장하지 않는다.
<!-- body -->
## 이미지 수집
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
라이프사이클을 관리한다.
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
이미지들을 삭제한다.
## 컨테이너 수집
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다.
`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다.
`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름)
쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다.
`MaxContainers` 는 죽은 컨테이너의 최대 수량이다.
이러한 변수는 `MinAge` 를 0으로 설정하고,
`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다.
Kubelet은 미확인, 삭제 또는 앞에서 언급한
플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다.
일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는
파드 당 최대
컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의
전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다.
다음의 상황에서 `MaxPerPodContainer` 가 조정된다.
최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고
가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는
`MinAge` 보다 오래되면 제거된다.
kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.
## 사용자 설정
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
기본값은 85% 이다.
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
기본값은 80% 이다.
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
인스턴스의 최대 수. 기본 값은 1 이다.
3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
의 값도 상대적으로 더 큰 값을 권장한다.
자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
## 사용 중단(Deprecation)
문서에 있는 몇 가지 kubelet의 가비지 수집 특징은 향후에 kubelet 축출(eviction) 기능으로 대체될 예정이다.
포함:
| 기존 Flag | 신규 Flag | 근거 |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | 기존의 축출 신호로 인하여 이미지 가비지 수집이 트리거 될 수 있음 |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 축출 리클레임 기능이 동일한 행동을 수행 |
| `--maximum-dead-containers` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--maximum-dead-containers-per-container` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--minimum-container-ttl-duration` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 |
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.

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

@ -160,7 +160,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
분리할 수 ​​있고, 이 중 일부는 `stdout` 또는 `stderr` 에
분리할 수 있고, 이 중 일부는 `stdout` 또는 `stderr` 에
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
`stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은

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

@ -397,7 +397,7 @@ deployment.apps/my-nginx configured
rm /tmp/nginx.yaml
```
이를 통해 보다 중요한 변경을 더 쉽게 ​​수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
이를 통해 보다 중요한 변경을 더 쉽게 수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
더 자세한 내용은, [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 문서를 참고하길 바란다.

60
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -30,46 +30,7 @@ weight: 50
찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신
다른 접근법을 취한다.
## 쿠버네티스 네트워크 모델
모든 `Pod` 에는 고유의 IP 주소가 있다. 즉, `Pod` 간에 링크를 명시적으로
생성할 필요가 없으며 컨테이너 포트를 호스트 포트에 매핑할
필요가 거의 없다. 이렇게 하면 포트 할당, 이름 지정, 서비스 검색, 로드 밸런싱,
애플리케이션 구성 및 마이그레이션 관점에서 `Pod` 를 VM 또는
물리적 호스트처럼 취급할 수 있는 깔끔하고, 하위 호환성
있는 모델이 생성된다.
쿠버네티스는 모든 네트워크 구현에 다음과 같은
기본 요구 사항을 적용한다(의도적 네트워크 세분화 정책 제외).
* 노드의 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
* 노드의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
파드와 통신할 수 있다.
참고: 호스트 네트워크에서 실행되는 `Pod` 를 지원하는 리눅스와 같은 플랫폼의 경우, 다음의 요구 사항을
적용한다.
* 노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드에 있는 모든
파드와 통신할 수 있다.
이 모델은 전체적으로 덜 복잡할 뿐만 아니라, 쿠버네티스를 위해 VM에서
컨테이너로 애플리케이션을 포팅할 때 충돌이 적게 구현하려는 요구와
주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
한다.
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다.
`Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를
요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은
컨테이너 런타임의 세부 사항이기도 하다. `Pod` 자체는
호스트 포트의 존재 여부에 대해 인식하지 못한다.
쿠버네티스 네트워킹 모델에 대한 상세 정보는 [여기](/ko/docs/concepts/services-networking/)를 참고한다.
## 쿠버네티스 네트워크 모델의 구현 방법
@ -106,7 +67,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
### 캘리코
[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
[캘리코](https://projectcalico.docs.tigera.io/about/about-calico/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
### 실리움(Cilium)
@ -118,9 +79,9 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
### 화웨이의 CNI-Genie
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
[CNI-Genie](https://github.com/cni-genie/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/flannel-io/flannel#flannel), [캘리코](https://projectcalico.docs.tigera.io/about/about-calico/), [위브넷(Weave-net)](https://www.weave.works/oss/net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
### cni-ipvlan-vpc-k8s
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)는
@ -143,9 +104,10 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
### 콘티브(Contiv)
### 콘티브-VPP(Contiv-VPP)
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
[Contiv-VPP](https://contivpp.io/)는 유저 스페이스에서 동작하고 성능을 중시하는 쿠버네티스 네트워크 플러그인이며,
데이터 플레인으로 [fd.io](https://fd.io/)를 사용한다.
### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
@ -165,10 +127,14 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
### 플라넬
[플라넬](https://github.com/coreos/flannel#flannel)은 쿠버네티스 요구 사항을
[플라넬](https://github.com/flannel-io/flannel#flannel)은 쿠버네티스 요구 사항을
충족하는 매우 간단한 오버레이 네트워크이다. 많은
경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.
### Hybridnet
[Hybridnet](https://github.com/alibaba/hybridnet)은 하이브리드 클라우드를 위해 디자인된 오픈소스 CNI 플러그인이며 하나 또는 다수의 클러스터에 있는 컨테이너를 위한 오버레이 및 언더레이 네트워킹을 제공한다. 오버레이 및 언더레이 컨테이너는 동일한 노드에서 실행될 수 있으며 클러스터 범위의 양방향 네트워크 연결성을 가진다.
### 재규어(Jaguar)
[재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
@ -227,7 +193,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
### Weaveworks의 위브넷
[위브넷](https://www.weave.works/products/weave-net/)은
[위브넷](https://www.weave.works/oss/net/)은
쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다.
위브넷은 [CNI 플러그인](https://www.weave.works/docs/net/latest/cni-plugin/) 또는
독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며,

91
content/ko/docs/concepts/cluster-administration/system-logs.md
View File

@ -17,23 +17,70 @@ weight: 60
## Klog
klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)는
쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
쿠버네티스는 각 컴포넌트의 로깅을 간소화하는 중에 있다.
다음 klog 명령줄 플래그는 쿠버네티스 1.23에서
[사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)되었으며
이후 릴리스에서 제거될 것이다.
- `--add-dir-header`
- `--alsologtostderr`
- `--log-backtrace-at`
- `--log-dir`
- `--log-file`
- `--log-file-max-size`
- `--logtostderr`
- `--one-output`
- `--skip-headers`
- `--skip-log-headers`
- `--stderrthreshold`
출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다.
출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다.
이는 POSIX 셸 또는 systemd와 같은 도구일 수
있다.
배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서,
위의 옵션은 사용할 수 없다.
그런 경우 출력을 리다이렉트하기 위해
[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다.
미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와
서버 및 노드 릴리스 아카이브에는 `kube-log-runner`라는 이름으로 포함되어 있다.
다음 표는 각 `kube-log-runner` 실행법이 어떤 셸 리다이렉션에 해당되는지 보여준다.
| 사용법 | POSIX 셸 (예:) bash) | `kube-log-runner <options> <cmd>` |
| -----------------------------------------|----------------------------|-------------------------------------------------------------|
| stderr와 stdout을 합치고, stdout으로 출력 | `2>&1` | `kube-log-runner` (기본 동작)) |
| stderr와 stdout을 로그 파일에 기록 | `1>>/tmp/log 2>&1` | `kube-log-runner -log-file=/tmp/log` |
| 로그 파일에 기록하면서 stdout으로 출력 | `2>&1 \| tee -a /tmp/log` | `kube-log-runner -log-file=/tmp/log -also-stdout` |
| stdout만 로그 파일에 기록 | `>/tmp/log` | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
### Klog 출력
klog 네이티브 형식 예 :
```
I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
```
메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다.
```
I1025 00:15:15.525108 1 example.go:79] This is a message
which has a line break.
```
### 구조화된 로깅
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{<warning>}}
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을
파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
{{< warning >}}
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
로그 형식 및 값 직렬화는 변경될 수 있다.
{{< /warning>}}
@ -42,7 +89,8 @@ I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/
로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다.
새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다.
구조화된 로그 형식:
구조화된 로그 메시지의 기본 형식은 텍스트이며,
기존 klog와 하위 호환되는 형식이다.
```ini
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
@ -54,24 +102,28 @@ I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
```
문자열은 따옴표로 감싸진다. 다른 값들은
[`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해
[데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다.
```
I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
second line.}
```
### JSON 로그 형식
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{<warning >}}
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
필드 이름과 JSON 직렬화는 변경될 수 있다.
{{< /warning >}}
`--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다.
JSON 로그 형식 예시(보기좋게 출력된 형태):
JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
```json
{
"ts": 1580306777.04728,
@ -106,9 +158,8 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다.
{{< /warning >}}
`--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화 한다.
활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고
이러한 필드의 로깅이 방지된다.
`--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화한다.
활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 이러한 필드의 로깅이 방지된다.
현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록:
* kube-controller-manager
@ -122,16 +173,17 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
### 로그 상세 레벨(verbosity)
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면
기록된 이벤트 수가 줄어든다.
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다.
로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다.
### 로그 위치
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 예를 들면 다음과 같다.
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
예를 들면 다음과 같다.
* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
* kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다.
* kubelet과 {{<glossary_tooltip term_id="container-runtime" text="컨테이너 런타임">}}은
컨테이너에서 실행되지 않는다.
systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 jounald에 기록한다.
그 외 시스템에서는, `/var/log` 디렉터리의 `.log` 파일에 기록한다.
@ -145,4 +197,5 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
* [klog 플래그 사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) 알아보기
* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기

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

@ -239,6 +239,10 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
{{< note >}}
컨피그맵을 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 받지 못할 것이다.
{{< /note >}}
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}

300
content/ko/docs/concepts/configuration/manage-resources-containers.md
View File

@ -1,11 +1,12 @@
---
title: 컨테이너 리소스 관리
title: 파드 및 컨테이너 리소스 관리
content_type: concept
weight: 40
feature:
title: 자동 빈 패킹(bin packing)
description: >
리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다. 활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다.
리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다.
활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다.
---
<!-- overview -->
@ -14,7 +15,8 @@ feature:
{{< glossary_tooltip text="컨테이너" term_id="container" >}}에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다.
지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다.
파드에서 컨테이너에 대한 리소스 _요청(request)_ 을 지정하면, 스케줄러는 이 정보를
파드에서 컨테이너에 대한 리소스 _요청(request)_ 을 지정하면,
{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}는 이 정보를
사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 _제한(limit)_ 을
지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를
사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은
@ -56,7 +58,7 @@ feature:
*CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다.
CPU는 컴퓨팅 처리를 나타내며 [쿠버네티스 CPU](#cpu의-의미) 단위로 지정된다.
메모리는 바이트 단위로 지정된다.
쿠버네티스 v1.14 이상을 사용하는 경우, _huge page_ 리소스를 지정할 수 있다.
리눅스 워크로드에 대해서는, _huge page_ 리소스를 지정할 수 있다.
Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
블록을 할당하는 리눅스 관련 기능이다.
@ -78,7 +80,8 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
## 파드와 컨테이너의 리소스 요청 및 제한
파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다.
각 컨테이너에 대해, 다음과 같은
리소스 제한(limit) 및 요청(request)을 지정할 수 있다.
* `spec.containers[].resources.limits.cpu`
* `spec.containers[].resources.limits.memory`
@ -87,35 +90,43 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
* `spec.containers[].resources.requests.memory`
* `spec.containers[].resources.requests.hugepages-<size>`
요청과 제한은 개별 컨테이너에서만 지정할 수 있지만,
파드 리소스 요청 및 제한에 대해 이야기하는 것이 편리하다.
특정 리소스 타입에 대한 *파드 리소스 요청/제한* 은 파드의 각 컨테이너에 대한
요청 및 제한은 개별 컨테이너에 대해서만 지정할 수 있지만,
한 파드의 총 리소스 요청 및 제한에 대해 생각해 보는 것도
유용할 수 있다.
특정 리소스 종류에 대해, *파드 리소스 요청/제한* 은 파드의 각 컨테이너에 대한
해당 타입의 리소스 요청/제한의 합이다.
## 쿠버네티스의 리소스 단위
### CPU의 의미
### CPU 리소스 단위 {#meaning-of-cpu}
CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다.
쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다.
쿠버네티스에서, 1 CPU 단위는 노드가 물리 호스트인지
아니면 물리 호스트 내에서 실행되는 가상 머신인지에 따라
**1 물리 CPU 코어** 또는 **1 가상 코어** 에 해당한다.
요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의
`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은,
`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다.
CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은
CPU 자원의 단위와 관련하여, `0.1` 이라는 [수량](/docs/reference/kubernetes-api/common-definitions/quantity/) 표현은
"백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은
"백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며,
`1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로,
`100m` 과 같은 형식이 선호될 수 있다.
CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다.
CPU 리소스는 항상 리소스의 절대량으로 표시되며, 상대량으로 표시되지 않는다.
예를 들어, 컨테이너가 싱글 코어, 듀얼 코어, 또는 48 코어 머신 중 어디에서 실행되는지와 상관없이
`500m` CPU는 거의 같은 양의 컴퓨팅 파워를 가리킨다.
### 메모리의 의미
{{< note >}}
쿠버네티스에서 CPU 리소스를 `1m`보다 더 정밀한 단위로 표기할 수 없다.
이 때문에, CPU 단위를 `1.0` 또는 `1000m`보다 작은 밀리CPU 형태로 표기하는 것이 유용하다.
예를 들어, `0.005` 보다는 `5m`으로 표기하는 것이 좋다.
{{< /note >}}
### 메모리 리소스 단위 {#meaning-of-memory}
`memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를
E, P, T, G, M, k 와 같은
[수량](/docs/reference/kubernetes-api/common-definitions/quantity/) 접미사 중 하나를 사용하여 메모리를
일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
@ -123,13 +134,20 @@ E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메
128974848, 129e6, 129M, 128974848000m, 123Mi
```
다음은 예제이다.
다음 파드에는 두 개의 컨테이너가 있다. 각 컨테이너에는 0.25 cpu와
64MiB(2<sup>26</sup> 바이트)의 메모리 요청이 있다. 각 컨테이너는 0.5
cpu와 128MiB 메모리로 제한된다. 파드에 0.5 cpu와 128 MiB
메모리, 1 cpu와 256MiB 메모리 제한이 있다고 말할 수 있다.
접미사의 대소문자에 유의한다.
`400m`의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다.
이 사람은 아마도 400 메비바이트(mebibytes) (`400Mi`) 또는 400 메가바이트 (`400M`) 를 요청하고 싶었을 것이다.
## 컨테이너 리소스 예제 {#example-1}
다음 파드는 두 컨테이너로 구성된다.
각 컨테이너는 0.25 CPU와 64 MiB(2<sup>26</sup> 바이트) 메모리 요청을 갖도록 정의되어 있다.
또한 각 컨테이너는 0.5 CPU와 128 MiB 메모리 제한을 갖는다.
이 경우 파드는 0.5 CPU와 128 MiB 메모리 요청을 가지며,
1 CPU와 256 MiB 메모리 제한을 갖는다.
```yaml
---
apiVersion: v1
kind: Pod
metadata:
@ -162,55 +180,54 @@ spec:
선택한다. 각 노드는 파드에 제공할 수 있는 CPU와 메모리 양과 같은 각 리소스 타입에 대해
최대 용량을 갖는다. 스케줄러는 각 리소스 타입마다
스케줄된 컨테이너의 리소스 요청 합계가
노드 용량보다 작도록 한다. 참고로 노드의 실제 메모리나
노드 용량보다 작도록 한다.
참고로 노드의 실제 메모리나
CPU 리소스 사용량은 매우 적지만, 용량 확인에 실패한 경우
스케줄러는 여전히 노드에 파드를 배치하지 않는다. 이는 리소스 사용량이
나중에 증가할 때, 예를 들어, 일일 요청 비율이
최대일 때 노드의 리소스 부족을 방지한다.
## 리소스 제한이 있는 파드가 실행되는 방법
## 쿠버네티스가 리소스 요청 및 제한을 적용하는 방법 {#how-pods-with-resource-limits-are-run}
kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을
컨테이너 런타임으로 전달한다.
kubelet이 파드의 컨테이너를 시작할 때,
kubelet은 해당 컨테이너의 메모리/CPU 요청 및 제한을 컨테이너 런타임에 전달한다.
도커를 사용하는 경우에는 다음과 같다.
리눅스에서, 일반적으로 컨테이너 런타임은
적용될 커널 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 설정하고,
명시한 제한을 적용한다.
- `spec.containers[].resources.requests.cpu` 는 잠재적인 분수이며,
1024를 곱한 값인 코어 값으로 변환된다. 이 숫자 또는 2보다
큰 값은 `docker run` 명령에서
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)
플래그의 값으로 사용된다.
- CPU 제한은 해당 컨테이너가 사용할 수 있는 CPU 시간에 대한 강한 상한(hard ceiling)을 정의한다.
각 스케줄링 간격(시간 조각)마다, 리눅스 커널은 이 제한이 초과되었는지를 확인하고,
만약 초과되었다면 cgroup의 실행 재개를 허가하지 않고 기다린다.
- CPU 요청은 일반적으로 가중치 설정(weighting)을 정의한다.
현재 부하율이 높은 시스템에서 여러 개의 컨테이너(cgroup)가 실행되어야 하는 경우,
큰 CPU 요청값을 갖는 워크로드가 작은 CPU 요청값을 갖는 워크로드보다 더 많은 CPU 시간을 할당받는다.
- 메모리 요청은 주로 (쿠버네티스) 파드 스케줄링 과정에서 사용된다.
cgroup v2를 사용하는 노드에서, 컨테이너 런타임은 메모리 요청을 힌트로 사용하여
`memory.min` 및 `memory.low`을 설정할 수 있다.
- 메모리 제한은 해당 cgroup에 대한 메모리 사용량 상한을 정의한다.
컨테이너가 제한보다 더 많은 메모리를 할당받으려고 시도하면,
리눅스 커널의 메모리 부족(out-of-memory) 서브시스템이 활성화되고
(일반적으로) 개입하여 메모리를 할당받으려고 했던 컨테이너의 프로세스 중 하나를 종료한다.
해당 프로세스의 PID가 1이고, 컨테이너가 재시작 가능(restartable)으로 표시되어 있으면, 쿠버네티스가 해당 컨테이너를 재시작한다.
- 파드 또는 컨테이너의 메모리 제한은 메모리 기반 볼륨(예: `emptyDir`)의 페이지에도 적용될 수 있다.
kubelet은 `tmpfs` emptyDir 볼륨을 로컬 임시(ephemeral) 스토리지가 아닌
컨테이너 메모리 사용으로 간주하여 추적한다.
- 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고
100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 마이크로초 단위의
총 CPU 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다.
한 컨테이너가 메모리 요청을 초과하고
해당 노드의 메모리가 부족하지면,
해당 컨테이너가 속한 파드가 {{< glossary_tooltip text="축출" term_id="eviction" >}}될 수 있다.
{{< note >}}
기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다.
{{</ note >}}
컨테이너가 비교적 긴 시간 동안 CPU 제한을 초과하는 것이 허용될 수도, 허용되지 않을 수도 있다.
그러나, 컨테이너 런타임은 과도한 CPU 사용률을 이유로 파드 또는 컨테이너를 종료시키지는 않는다.
- `spec.containers[].resources.limits.memory` 는 정수로 변환되어,
`docker run` 명령에서
[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)
플래그의 값으로 사용된다.
컨테이너가 메모리 제한을 초과하면, 컨테이너는 종료될 수 있다. 다시
시작할 수 있으면, 다른 타입의 런타임 오류와 마찬가지로, kubelet이 다시
시작한다.
컨테이너가 메모리 요청을 초과하면, 노드에 메모리가
부족할 때마다 파드가 축출될 수 있다.
컨테이너가 오랫동안 CPU 제한을 초과하는 것은 허용되거나 허용되지
않을 수 있다. 그러나, 과도한 CPU 사용으로 인해 종료되지는 않는다.
리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는
종료 중인지 확인하려면,
리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는 종료 중인지 확인하려면,
[문제 해결](#문제-해결) 섹션을 참조한다.
### 컴퓨트 및 메모리 리소스 사용량 모니터링
파드의 리소스 사용량은 파드 상태의 일부로 보고된다.
kubelet은 파드의 리소스 사용량을 파드
[`status`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)에 포함하여 보고한다.
클러스터에서 선택적인 모니터링 도구를
사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-api)에서
@ -308,21 +325,26 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으
### 로컬 임시 스토리지에 대한 요청 및 제한 설정
_임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수 있다. 파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다.
`ephemeral-storage`를 명시하여 로컬 임시 저장소를 관리할 수 있다.
파드의 각 컨테이너는 다음 중 하나 또는 모두를 명시할 수 있다.
* `spec.containers[].resources.limits.ephemeral-storage`
* `spec.containers[].resources.requests.ephemeral-storage`
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와
같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
예를 들어, 다음은 대략 동일한 값을 나타낸다.
예를 들어, 다음은 거의 동일한 값을 나타낸다.
```shell
128974848, 129e6, 129M, 123Mi
```
- `128974848`
- `129e6`
- `129M`
- `123Mi`
다음 예에서, 파드에 두 개의 컨테이너가 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
다음 예에서, 파드에 두 개의 컨테이너가 있다.
각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다.
각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다.
따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
```yaml
apiVersion: v1
@ -356,10 +378,12 @@ spec:
emptyDir: {}
```
### 임시-스토리지 요청이 있는 파드의 스케줄링 방법
### `ephemeral-storage` 요청이 있는 파드의 스케줄링 방법
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를
선택한다. 각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다. 자세한 정보는, [노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다.
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를 선택한다.
각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다.
자세한 정보는,
[노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다.
스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드 용량보다 작도록 한다.
@ -492,15 +516,19 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 참조한다.
##### 기타 리소스
새로운 노드-레벨의 확장된 리소스를 알리기 위해, 클러스터 운영자는
API 서버에 `PATCH` HTTP 요청을 제출하여 클러스터의
노드에 대해 `status.capacity` 에서 사용할 수 있는 수량을 지정할 수 있다. 이 작업
후에는, 노드의 `status.capacity` 에 새로운 리소스가 포함된다. 이
`status.allocatable` 필드는 kubelet에 의해 비동기적으로 새로운
리소스로 자동 업데이트된다. 참고로 스케줄러가 파드 적합성을 평가할 때 노드
`status.allocatable` 값을 사용하므로, 노드 용량을
새 리소스로 패치하는 것과 해당 노드에서 리소스를 스케줄하도록 요청하는 첫 번째 파드
사이에 약간의 지연이 있을 수 있다.
리소스로 자동 업데이트된다.
스케줄러가 파드 적합성을 평가할 때 노드의 `status.allocatable` 값을 사용하므로,
스케줄러는 해당 비동기 업데이트 이후의 새로운 값만을 고려한다.
따라서 노드 용량을 새 리소스로 패치하는 시점과
해당 자원을 요청하는 첫 파드가 해당 노드에 스케줄될 수 있는 시점 사이에
약간의 지연이 있을 수 있다.
**예제:**
@ -527,7 +555,7 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.
[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
[스케줄러 구성](/docs/reference/config-api/kube-scheduler-config.v1beta3/)에서
스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.
**예제:**
@ -610,26 +638,31 @@ spec:
## PID 제한
프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
프로세스 ID(PID) 제한은 kubelet의 구성에 대해
주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다.
자세한 내용은 [PID 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
## 문제 해결
### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다
### 내 파드가 `FailedScheduling` 이벤트 메시지로 보류 중이다
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를
찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이
파드의 위치를 ​​찾지 못하면 이벤트가 생성된다.
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면,
노드를 찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다.
파드가 할당될 곳을 스케줄러가 찾지 못하면
[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)가 생성된다.
다음과 같이 `kubectl`을 사용하여 파드의 이벤트를 볼 수 있다.
```shell
kubectl describe pod frontend | grep -A 3 Events
kubectl describe pod frontend | grep -A 9999999999 Events
```
```
Events:
FirstSeen LastSeen Count From Subobject PathReason Message
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu
```
위의 예에서, 노드의 CPU 리소스가 충분하지 않아 이름이
위의 예에서, 모든 노드의 CPU 리소스가 충분하지 않아 이름이
"frontend"인 파드를 스케줄하지 못했다. 비슷한 메시지로
메모리 부족(PodExceedsFreeMemory)으로 인한 장애도 알릴 수 있다. 일반적으로, 파드가
이 타입의 메시지로 보류 중인 경우, 몇 가지 시도해 볼 것들이 있다.
@ -639,6 +672,9 @@ Events:
- 파드가 모든 노드보다 크지 않은지 확인한다. 예를 들어, 모든
노드의 용량이 `cpu: 1` 인 경우, `cpu: 1.1` 요청이 있는 파드는
절대 스케줄되지 않는다.
- 노드 테인트를 확인한다.
대부분의 노드에 테인트가 걸려 있고, 신규 파드가 해당 테인트에 배척된다면,
스케줄러는 해당 테인트가 걸려 있지 않은 나머지 노드에만 배치를 고려할 것이다.
`kubectl describe nodes` 명령으로 노드 용량과 할당된 양을
확인할 수 있다. 예를 들면, 다음과 같다.
@ -673,21 +709,34 @@ Allocated resources:
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
```
위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
요청하는 것은 노드에 맞지 않음을 알 수 있다.
위의 출력에서, 1.120 이상의 CPU 또는 6.23 Gi 이상의 메모리를 요청하는 파드는
노드에 할당될 수 없음을 확인할 수 있다.
`Pods` 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을
"Pods" 섹션을 살펴보면, 어떤 파드가 노드에서 공간을 차지하고 있는지를
볼 수 있다.
시스템 데몬이 사용 가능한 리소스의 일부를 사용하기 때문에, 파드에
사용 가능한 리소스의 양이 노드 용량보다 적다. `allocatable` 필드
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)는
파드가 사용할 수 있는 리소스의 양을 제공한다. 자세한 정보는
[노드 할당 가능 리소스](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md)를 참조한다.
사용 가능한 리소스의 일부를 시스템 데몬이 사용하기 때문에,
파드에 사용 가능한 리소스의 양은 노드 총 용량보다 적다.
쿠버네티스 API에서, 각 노드는 `.status.allocatable` 필드(상세 사항은
[NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) 참조)를
갖는다.
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/) 기능은
소비될 수 있는 리소스의 총량을 제한하도록 구성할 수 있다. 네임스페이스와
함께 사용하면, 한 팀이 모든 리소스를 사용하는 경우를 방지할 수 있다.
`.status.allocatable` 필드는 해당 노드에서 파드가 사용할 수 있는
리소스의 양을 표시한다(예: 15 vCPUs 및 7538 MiB 메모리).
쿠버네티스의 노드 할당 가능 리소스에 대한 상세 사항은
[시스템 데몬을 위한 컴퓨트 자원 예약하기](/docs/tasks/administer-cluster/reserve-compute-resources/)를 참고한다.
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하여,
한 네임스페이스가 사용할 수 있는 리소스 총량을 제한할 수 있다.
특정 네임스페이스 내에 ResourceQuota가 설정되어 있으면
쿠버네티스는 오브젝트에 대해 해당 쿼터를 적용한다.
예를 들어, 각 팀에 네임스페이스를 할당한다면, 각 네임스페이스에 ResourceQuota를 설정할 수 있다.
리소스 쿼터를 설정함으로써 한 팀이 지나치게 많은 리소스를 사용하여
다른 팀에 영향을 주는 것을 막을 수 있다.
해당 네임스페이스에 어떤 접근을 허용할지도 고려해야 한다.
네임스페이스에 대한 **완전한** 쓰기 권한을 가진 사람은
어떠한 리소스(네임스페이스에 설정된 ResourceQuota 포함)라도 삭제할 수 있다.
### 내 컨테이너가 종료되었다
@ -698,6 +747,8 @@ Allocated resources:
```shell
kubectl describe pod simmemleak-hra99
```
출력은 다음과 같다.
```
Name: simmemleak-hra99
Namespace: default
@ -708,56 +759,47 @@ Status: Running
Reason:
Message:
IP: 10.244.2.75
Replication Controllers: simmemleak (1/1 replicas created)
Containers:
simmemleak:
Image: saadali/simmemleak
Image: saadali/simmemleak:latest
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Tue, 07 Jul 2015 12:54:41 -0700
Last Termination State: Terminated
Exit Code: 1
Started: Fri, 07 Jul 2015 12:54:30 -0700
Finished: Fri, 07 Jul 2015 12:54:33 -0700
Ready: False
Restart Count: 5
cpu: 100m
memory: 50Mi
State: Running
Started: Tue, 07 Jul 2019 12:54:41 -0700
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Started: Fri, 07 Jul 2019 12:54:30 -0700
Finished: Fri, 07 Jul 2019 12:54:33 -0700
Ready: False
Restart Count: 5
Conditions:
Type Status
Ready False
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine
Normal Created 41s kubelet Created container simmemleak
Normal Started 40s kubelet Started container simmemleak
Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod
```
앞의 예제에서, `Restart Count: 5` 표시는 파드의 `simmemleak`
컨테이너가 종료되고 5번 다시 시작되었음을 나타낸다.
컨테이너가 종료되고 (지금까지) 5번 다시 시작되었음을 나타낸다.
`Reason: OOMKilled`를 통해 컨테이너가 제한보다 많은 양의 메모리를 사용하려고 했다는 것을 확인할 수 있다.
이전에 종료된 컨테이너의 상태를 가져오기 위해 `-o go-template=...` 옵션을 사용해서
`kubectl get pod` 를 호출할 수 있다.
```shell
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
```
```
Container Name: simmemleak
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
```
컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다.
다음 단계로 메모리 누수가 있는지 애플리케이션 코드를 확인해 볼 수 있다.
애플리케이션이 예상한 대로 동작하는 것을 확인했다면,
해당 컨테이너의 메모리 제한(및 요청)을 더 높게 설정해 본다.
## {{% heading "whatsnext" %}}
* [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
* 요청과 제한의 차이점에 대한 자세한 내용은,
[리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다.
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
* API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와
[컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다.
* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기
* [kube-scheduler 정책 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)에 대해 더 읽어보기

2
content/ko/docs/concepts/containers/_index.md
View File

@ -13,7 +13,7 @@ no_list: true
의미한다.
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.

3
content/ko/docs/concepts/containers/container-environment.md
View File

@ -34,7 +34,7 @@ weight: 20
파드 이름과 네임스페이스는
[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
컨테이너 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
### 클러스터 정보
@ -42,7 +42,6 @@ Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
있다.
이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
이러한 환경 변수는 Docker 링크 구문과 일치한다.
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
다음의 형태로 변수가 정의된다.

4
content/ko/docs/concepts/containers/images.md
View File

@ -436,7 +436,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
- 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
- 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
- 쿠버네티스 구성은 필요 없다.
- 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
- 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
- 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
@ -456,5 +456,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
## {{% heading "whatsnext" %}}
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
* [컨테이너 이미지 가비지 수집(garbage collection)](/ko/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry)

5
content/ko/docs/concepts/containers/runtime-class.md
View File

@ -109,6 +109,11 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
#### dockershim
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
dockershim은 쿠버네티스 v1.20에서 사용 중단되었으며, v1.24에서 제거될 것이다. 상세 사항은
[dockershim 사용 중단](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)을 참고한다.
dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.

2
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
### 인가
[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
### 동적 어드미션 컨트롤

4
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -145,7 +145,7 @@ CRD 오브젝트의 이름은 유효한
## API 서버 애그리게이션
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다.
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
@ -180,7 +180,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
| ------- | ----------- | ---- | -------------- |
| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. |
| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 |
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
| 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 |
| 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 |
| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 |

21
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -1,7 +1,6 @@
---
title: 장치 플러그인
description: GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다.
description: 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다.
content_type: concept
weight: 20
---
@ -48,13 +47,15 @@ service Registration {
노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어
노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다.
그러고 나면, 사용자가
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 명세에 있는 장치를 요청할 수 있다.
다만, 다른 종류의 리소스를 요청하는 것이므로 다음과 같은 제한이 있다.
그러고 나면, 사용자가 장치를 파드 스펙의 일부로 요청할 수
있다([`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 참조).
확장 리소스를 요청하는 것은 다른 자원의 요청 및 제한을 관리하는 것과 비슷하지만,
다음과 같은 차이점이 존재한다.
* 확장된 리소스는 정수(integer) 형태만 지원되며 오버커밋(overcommit) 될 수 없다.
* 컨테이너간에 장치를 공유할 수 없다.
### 예제 {#example-pod}
쿠버네티스 클러스터가 특정 노드에서 `hardware-vendor.example/foo` 리소스를 알리는 장치 플러그인을 실행한다고
가정해 보자. 다음은 데모 워크로드를 실행하기 위해 이 리소스를 요청하는 파드의 예이다.
@ -287,7 +288,7 @@ message AllocatableResourcesResponse {
```
쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다.
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
끄면 된다.
쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다.
@ -302,7 +303,7 @@ NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값
gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
에이전트는 특권을 가진 ​​보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
에이전트는 특권을 가진 보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
데몬셋으로 실행 중인 경우, 해당 장치 모니터링 에이전트의 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
## 장치 플러그인 예시 {#examples}
{{% thirdparty-content %}}
다음은 장치 플러그인 구현의 예이다.
* [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
@ -357,5 +360,5 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
* 쿠버네티스에서 [TLS 인그레스에 하드웨어 가속](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기

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

@ -42,9 +42,10 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 |
| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 |
위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.
위 레이블의 실제 예시는 다음 {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} 오브젝트를 고려한다.
```yaml
# 아래는 전체 명세의 일부분이다
apiVersion: apps/v1
kind: StatefulSet
metadata:

21
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -95,7 +95,26 @@ kubectl config view --minify | grep namespace:
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
네임스페이스를 넘어서 접근하기 위해서는,
전체 주소 도메인 이름(FQDN)을 사용해야 한다.
그렇기 때문에, 모든 네임스페이스 이름은 유효한
[RFC 1123 DNS 레이블](/ko/docs/concepts/overview/working-with-objects/names/#dns-label-names)이어야 한다.
{{< warning >}}
네임스페이스의 이름을 [공개 최상위 도메인](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 중 하나와 동일하게 만들면,
해당 네임스페이스 내의 서비스의 짧은 DNS 이름이 공개 DNS 레코드와 겹칠 수 있다.
어떠한 네임스페이스 내의 워크로드가
[접미점(trailing dot)](https://datatracker.ietf.org/doc/html/rfc1034#page-8) 없이 DNS 룩업을 수행하면
공개 DNS 레코드보다 우선하여 해당 서비스로 리다이렉트될 것이다.
이를 방지하기 위해, 신뢰하는 사용자만 네임스페이스를
생성할 수 있도록 권한을 제한한다.
필요한 경우, 추가적으로 써드파티 보안 컨트롤을 구성할 수 있으며,
예를 들어 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 이용하여
[공개 TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)와
동일한 이름의 네임스페이스 생성을 금지시킬 수 있다.
{{< /warning >}}
## 모든 오브젝트가 네임스페이스에 속하지는 않음

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

@ -11,8 +11,9 @@ weight: 30
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, v1.25에서 제거될 예정이다.
파드시큐리티폴리시는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)으로 대체되었다.
사용 중단에 대한 상세 사항은 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.
@ -21,7 +22,7 @@ weight: 30
## 파드 시큐리티 폴리시란?
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 ​​클러스터-레벨의
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
조건 셋을 정의한다. 관리자는
@ -195,7 +196,7 @@ API 서버 접근 제어에 대한 자세한 내용은
## 정책 순서
파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여
제어하는 ​​많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는
다음 기준에 따라 정책을 선택한다.

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

@ -104,7 +104,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
지정된 네임스페이스에서 요청할 수 있는 총 [스토리지 리소스](/ko/docs/concepts/storage/persistent-volumes/) 합을 제한할 수 있다.
또한 연관된 ​​스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
또한 연관된 스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
| 리소스 이름 | 설명 |
| --------------------- | ----------------------------------------------------------- |

4
content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
View File

@ -87,7 +87,7 @@ Kubelet은 다른 구성은 지원하지 않는다.
{{<note>}}
일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/cluster-administration/kubelet-garbage-collection/#사용-중단-deprecation)을 참조한다.
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/architecture/garbage-collection/#containers-images)을 참조한다.
{{</note>}}
### 축출 임계값
@ -235,7 +235,7 @@ QoS는 EphemeralStorage 요청에 적용되지 않으므로,
`Guaranteed` 파드는 모든 컨테이너에 대해 자원 요청량과 제한이 명시되고
그 둘이 동일할 때에만 보장(guaranteed)된다. 다른 파드의 자원 사용으로 인해
`Guaranteed` 파드가 축출되는 일은 발생하지 않는다. 만약 시스템 데몬(예:
`kubelet`, `docker`, `journald`)이 `system-reserved` 또는 `kube-reserved`
`kubelet`, `journald`)이 `system-reserved` 또는 `kube-reserved`
할당을 통해 예약된 것보다 더 많은 자원을 소비하고, 노드에는 요청량보다 적은 양의
자원을 사용하고 있는 `Guaranteed` / `Burstable` 파드만 존재한다면,
kubelet은 노드 안정성을 유지하고 자원 고갈이 다른 파드에 미칠 영향을 통제하기 위해

8
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -106,7 +106,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
`PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
`preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
앞쪽에 배치되지만,
그 파드는 다른 파드를 축출할 수 없다.
스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고
@ -122,17 +122,17 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
비-선점 파드는 다른 우선순위가 높은 파드에 의해
축출될 수 있다.
`PreemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
`preemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수
있다(기존의 기본 동작과 동일).
`PreemptionPolicy` 가 `Never` 로 설정된 경우,
`preemptionPolicy` 가 `Never` 로 설정된 경우,
해당 프라이어리티클래스의 파드는 비-선점될 것이다.
예제 유스케이스는 데이터 과학 관련 워크로드이다.
사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만,
실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다.
클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면,
`PreemptionPolicy: Never` 의 우선순위가 높은 잡이
`preemptionPolicy: Never` 의 우선순위가 높은 잡이
다른 대기 중인 파드보다 먼저 스케줄링된다.
### 비-선점 프라이어리티클래스 예제

48
content/ko/docs/concepts/services-networking/_index.md
View File

@ -5,8 +5,50 @@ description: >
쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
---
## 쿠버네티스 네트워크 모델
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
애플리케이션 구성, 마이그레이션 관점에서 `파드`를
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
파드와 통신할 수 있다
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
다음의 요구사항도 존재한다.
* 한 노드의 호스트 네트워크에 있는 파드는
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다.
이는 동일한 기본 모델이다.
쿠버네티스 IP 주소는 `파드` 범주에 존재하며,
`파드` 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다.
이는 곧 `파드` 내의 컨테이너들이 각자의 포트에 `localhost`로 접근할 수 있음을 의미한다.
또한 `파드` 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데,
이는 VM 내 프로세스 간에도 마찬가지이다.
이러한 모델은 "파드 별 IP" 모델로 불린다.
이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.
`노드` 자체의 포트를 `파드`로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림),
이는 매우 비주류적인(niche) 동작이다.
포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다.
`파드` 자체는 호스트 포트 존재 유무를 인지할 수 없다.
쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다.
- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.

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

@ -13,11 +13,9 @@ weight: 30
## 컨테이너 연결을 위한 쿠버네티스 모델
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다.
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
podIP: 10.244.2.5
```
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.

5
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -106,10 +106,9 @@ SRV 레코드는 노멀 서비스 또는
`172-17-0-3.default.pod.cluster.local`.
서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된
모든 파드는 다음과 같은 DNS 주소를 갖는다.
서비스에 의해 노출된 모든 파드는 다음과 같은 DNS 주소를 갖는다.
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
### 파드의 hostname 및 subdomain 필드

8
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -57,6 +57,14 @@ IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* kubelet:
* `--cloud-provider`가 명시되지 않았다면
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
IP 패밀리 선호사항을 만족한다.
{{< note >}}
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)

2
content/ko/docs/concepts/services-networking/ingress-controllers.md
View File

@ -33,7 +33,7 @@ weight: 40
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md)는 인그레스 컨트롤러로서 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의

25
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -26,7 +26,7 @@ weight: 40
## 인그레스란?
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
{{< link text="서비스" url="/ko/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
@ -80,7 +80,7 @@ graph LR;
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
서로 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 서로 다른 어노테이션을 지원한다.
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@ -88,6 +88,15 @@ graph LR;
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
지시하는 규칙만 지원한다.
`ingressClassName`을 생략하려면, [기본 인그레스 클래스](#default-ingress-class)가
정의되어 있어야 한다.
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
하지만 [아래](#default-ingress-class)에 나와 있는 것과 같이 기본 `IngressClass`를 명시하는 것을
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
### 인그레스 규칙
각 HTTP 규칙에는 다음의 정보가 포함된다.
@ -339,6 +348,14 @@ spec:
기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
{{< /caution >}}
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
하지만 다음과 같이 기본 `IngressClass`를 명시하는 것을
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
{{< codenew file="service/networking/default-ingressclass.yaml" >}}
## 인그레스 유형들
### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
@ -468,9 +485,7 @@ graph LR;
트래픽을 일치 시킬 수 있다.
예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
트래픽은 `service3`로 라우팅 한다.
`service1`로, `second.bar.com`는 `service2`로, 그리고 요청 헤더가 `first.bar.com` 또는 `second.bar.com`에 해당되지 않는 모든 트래픽을 `service3`로 라우팅한다.
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}

32
content/ko/docs/concepts/services-networking/network-policies.md
View File

@ -10,7 +10,7 @@ weight: 50
<!-- overview -->
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. 네트워크폴리시는 한쪽 또는 양쪽 종단이 파드인 연결에만 적용되며, 다른 연결에는 관여하지 않는다.
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
@ -27,15 +27,17 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
## 격리 및 격리되지 않은 파드
## 파드 격리의 두 가지 종류
기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
파드 격리에는 이그레스에 대한 격리와 인그레스에 대한 격리의 두 가지 종류가 있다. 이들은 어떤 연결이 성립될지에 대해 관여한다. 여기서 "격리"는 절대적인 것이 아니라, "일부 제한이 적용됨"을 의미한다. 반대말인 "이그레스/인그레스에 대한 비격리"는 각 방향에 대해 제한이 적용되지 않음을 의미한다. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 두 종류 모두 파드 간 연결과 연관된다.
파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
기본적으로, 파드는 이그레스에 대해 비격리되어 있다. 즉, 모든 아웃바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Egress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 이그레스에 대해 격리된다. 이러한 정책은 파드의 이그레스에 적용된다고 말한다. 파드가 이그레스에 대해 격리되면, 파드에서 나가는 연결 중에서 파드의 이그레스에 적용된 NetworkPolicy의 `egress` 리스트에 허용된 연결만이 허용된다. `egress` 리스트 각 항목의 효과는 합산되어 적용된다.
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
기본적으로, 파드는 인그레스에 대해 비격리되어 있다. 즉, 모든 인바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Ingress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 인그레스에 대해 격리된다. 이러한 정책은 파드의 인그레스에 적용된다고 말한다. 파드가 인그레스에 대해 격리되면, 파드로 들어오는 연결 중에서 파드의 인그레스에 적용된 NetworkPolicy의 `ingress` 리스트에 허용된 연결만이 허용된다. `ingress` 리스트 각 항목의 효과는 합산되어 적용된다.
두 파드간 네트워크 흐름을 허용하기 위해서는, 소스 파드의 이그레스 정책과 목적지 파드의 인그레스 정책 모두가 해당 트래픽을 허용해야 한다. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하게 되어 있다면, 해당 트래픽은 거절될 것이다.
네트워크 폴리시가 충돌하는 경우는 없다. 네트워크 폴리시는 합산되어 적용된다. 특정 파드의 특정 방향에 대해 하나 또는 여러 개의 폴리시가 적용되면, 해당 파드의 해당 방향에 대해 허용된 연결은 모든 폴리시가 허용하는 연결의 합집합이다. 따라서, 판별 순서는 폴리시 결과에 영향을 미치지 않는다.
송신 파드에서 수신 파드로의 연결이 허용되기 위해서는, 송신 파드의 이그레스 폴리시와 수신 파드의 인그레스 폴리시가 해당 연결을 허용해야 한다. 만약 어느 한 쪽이라도 해당 연결을 허용하지 않으면, 연결이 되지 않을 것이다.
## 네트워크폴리시 리소스 {#networkpolicy-resource}
@ -176,18 +178,20 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
### 기본적으로 모든 인그레스 트래픽 거부
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 인그레스 격리 정책을 생성할 수 있다.
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스에 대해 여전히 격리된다. 이 정책은 다른 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
### 기본적으로 모든 인그레스 트래픽 허용
### 모든 인그레스 트래픽 허용
만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
한 네임스페이스의 모든 파드로의 인입(incoming) 연결을 허용하려면, 이를 명시적으로 허용하는 정책을 만들 수 있다.
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
이 정책이 존재하면, 해당 파드로의 인입 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
### 기본적으로 모든 이그레스 트래픽 거부
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
@ -195,14 +199,16 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
기본 인그레스 격리 정책을 변경하지 않는다.
모든 파드의 인그레스 격리 정책을 변경하지 않는다.
### 기본적으로 모든 이그레스 트래픽 허용
### 모든 이그레스 트래픽 허용
만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
한 네임스페이스의 모든 파드로부터의 모든 연결을 허용하려면, 해당 네임스페이스의 파드로부터 나가는(outgoing) 모든 연결을 명시적으로 허용하는 정책을 생성할 수 있다.
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
이 정책이 존재하면, 해당 파드에서 나가는 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로의 인그레스 격리에는 영향을 미치지 않는다.
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.

8
content/ko/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -9,7 +9,7 @@ weight: 45
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된
노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다.
@ -20,9 +20,9 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
## 서비스 내부 트래픽 정책 사용
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
`ServiceInternalTrafficPolicy`를 활성화한 후에
`ServiceInternalTrafficPolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는
베타 기능이며 기본적으로 활성화되어 있다.
이 기능이 활성화되어 있으면,
{{< glossary_tooltip text="서비스" term_id="service" >}}의
`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.

32
content/ko/docs/concepts/services-networking/service.md
View File

@ -61,7 +61,7 @@ _서비스_ 로 들어가보자.
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
질의할 수 ​​있다.
질의할 수 있다.
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
밸런서를 배치할 수 있는 방법을 제공한다.
@ -449,11 +449,8 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
### 환경 변수
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. [도커 링크
호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다.
`{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 환경 변수가 추가되는데, 이 때 서비스 이름은 대문자로, 하이픈(`-`)은 언더스코어(`_`)로 변환하여 사용한다. 또한 도커 엔진의 "_[레거시 컨테이너 연결](https://docs.docker.com/network/links/)_" 기능과 호환되는 변수([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)도 지원한다.
예를 들어, TCP 포트 6379를 개방하고
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
@ -687,21 +684,28 @@ kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화
#### 로드밸런서 NodePort 할당 비활성화
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
`type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며,
이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다.
노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우
해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로,
`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다.
다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.

158
content/ko/docs/concepts/services-networking/topology-aware-hints.md Normal file
View File

@ -0,0 +1,158 @@
---
title: 토폴로지 인지 힌트
content_type: concept
weight: 45
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써
토폴로지 인지 라우팅을 가능하게 한다.
이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며,
이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다.
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
인접성을 고려하여 트래픽을 라우트할 수 있다.
<!-- body -->
## 동기(motivation)
쿠버네티스 클러스터가 멀티-존(multi-zone) 환경에 배포되는 일이 점점 많아지고 있다.
_토폴로지 인지 힌트_ 는 트래픽이 발생한 존 내에서 트래픽을 유지하도록 처리하는 메커니즘을 제공한다.
이러한 개념은 보통 "토폴로지 인지 라우팅"이라고 부른다.
{{< glossary_tooltip text="서비스" term_id="Service" >}}의 엔드포인트를 계산할 때,
엔드포인트슬라이스 컨트롤러는 각 엔드포인트의 토폴로지(지역(region) 및 존)를 고려하여,
엔드포인트가 특정 존에 할당되도록 힌트 필드를 채운다.
그러면 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}와 같은
클러스터 구성 요소는 해당 힌트를 인식하고,
(토폴로지 상 가까운 엔드포인트를 사용하도록) 트래픽 라우팅 구성에 활용한다.
## 토폴로지 인지 힌트 사용하기
`service.kubernetes.io/topology-aware-hints` 어노테이션을 `auto`로 설정하여
서비스에 대한 토폴로지 인지 힌트를 활성화할 수 있다.
이는 엔드포인트슬라이스 컨트롤러가 안전하다고 판단되는 경우 토폴로지 힌트를 설정하도록 지시하는 것이다.
명심할 점은, 이를 수행한다고 해서 힌트가 항상 설정되는 것은 아니라는 것이다.
## 동작 방법 {#implementation}
이 기능을 동작시키는 요소는
엔드포인트슬라이스 컨트롤러와 kube-proxy 두 구성요소로 나눠져 있다.
이 섹션에서는 각 구성요소가 어떻게 이 기능을 동작시키는지에 대한 고차원 개요를 제공한다.
### 엔드포인트슬라이스 컨트롤러 {#implementation-control-plane}
엔드포인트슬라이스 컨트롤러는 이 기능이 활성화되어 있을 때
엔드포인트슬라이스에 힌트를 설정하는 일을 담당한다.
컨트롤러는 각 존에 일정 비율의 엔드포인트를 할당한다.
이 비율은 해당 존에 있는 노드의
[할당 가능한(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) CPU 코어에 의해 결정된다.
예를 들어, 한 존에 2 CPU 코어가 있고 다른 존에 1 CPU 코어만 있는 경우,
컨트롤러는 2 CPU 코어가 있는 존에 엔드포인트를 2배 할당할 것이다.
다음 예시는 엔드포인트슬라이스에 힌트가 채워졌을 때에 대한
예시이다.
```yaml
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: example-hints
labels:
kubernetes.io/service-name: example-svc
addressType: IPv4
ports:
- name: http
protocol: TCP
port: 80
endpoints:
- addresses:
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
zone: zone-a
hints:
forZones:
- name: "zone-a"
```
### kube-proxy {#implementation-kube-proxy}
kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 힌트를 기반으로
자신이 라우팅하는 엔드포인트를 필터링한다.
대부분의 경우, 이는 kube-proxy가 동일 존 내에서 트래픽을 엔드포인트로 라우팅할 수 있음을 뜻한다.
때때로 컨트롤러는 존 사이에 보다 균등한 엔드포인트 분배를 위해 다른 존으로부터 엔드포인트를 할당하기도 한다.
이러한 경우 일부 트래픽은 다른 존으로 라우팅될 것이다.
## 보호 규칙
쿠버네티스 컨트롤 플레인과 각 노드의 kube-proxy는
토폴로지 인지 힌트를 사용하기 전에 몇 가지 보호 규칙을 적용한다.
이들이 만족되지 않으면, kube-proxy는 존에 상관없이
클러스터의 모든 곳으로부터 엔드포인트를 선택한다.
1. **엔드포인트 수가 충분하지 않음:** 존의 숫자보다 엔드포인트의 숫자가 적으면,
컨트롤러는 어떤 힌트도 할당하지 않을 것이다.
2. **균형잡힌 할당이 불가능함:** 일부 경우에, 존 간 균형잡힌 엔드포인트 할당이 불가능할 수 있다.
예를 들어, zone-a가 zone-b보다 2배 큰 상황에서,
엔드포인트가 2개 뿐이라면,
zone-a에 할당된 엔드포인트는 zone-b에 할당된 엔드포인트보다 2배의 트래픽을 수신할 것이다.
컨트롤러는 이 "예상 과부하" 값을 각 존에 대해
허용 가능한 임계값보다 작게 낮출 수 없는 경우에는 힌트를 할당하지 않는다.
명심할 점은, 이것이 실시간 피드백 기반이 아니라는 것이다.
개별 엔드포인트가 과부하 상태로 바뀔 가능성도 여전히 있다.
3. **하나 이상의 노드에 대한 정보가 불충분함:** `topology.kubernetes.io/zone` 레이블이 없는 노드가 있거나
할당 가능한 CPU 값을 보고하지 않는 노드가 있으면,
컨트롤 플레인은 토폴로지 인지 엔드포인트를 설정하지 않으며
이로 인해 kube-proxy는 존 별로 엔드포인트를 필터링하지 않는다.
4. **하나 이상의 엔드포인트에 존 힌트가 없음:** 이러한 상황이 발생하면,
kube-proxy는 토폴로지 인지 힌트로부터의 또는 토폴로지 인지 힌트로의 전환이 진행 중이라고 가정한다.
이 상태에서 서비스의 엔드포인트를 필터링하는 것은 위험할 수 있으므로
kube-proxy는 모든 엔드포인트를 사용하는 모드로 전환된다.
5. **힌트에 존이 기재되지 않음:** kube-proxy가 실행되고 있는 존을 향하는 힌트를 갖는 엔드포인트를
하나도 찾지 못했다면,
모든 존에서 오는 엔드포인트를 사용하는 모드로 전환된다.
이러한 경우는 기존에 있던 클러스터에 새로운 존을 추가하는 경우에 발생할 가능성이 가장 높다.
## 제약사항
* 토폴로지 인지 힌트는 서비스의 `externalTrafficPolicy` 또는
`internalTrafficPolicy`가 `Local`로 설정된 경우에는 사용되지 않는다.
동일 클러스터의 서로 다른 서비스들에 대해 두 기능 중 하나를 사용하는 것은 가능하며,
하나의 서비스에 두 기능 모두를 사용하는 것은 불가능하다.
* 이러한 접근 방법은 존의 일부분에서
많은 트래픽이 발생하는 서비스에는 잘 작동하지 않을 것이다.
대신, 들어오는 트래픽이
각 존 내 노드 용량에 대략 비례한다고 가정한다.
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
준비되지 않은(unready) 노드는 무시한다.
이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다.
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
{{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}은 고려하지 않는다.
서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우,
이러한 상황은 고려되지 않을 것이다.
* 오토스케일링 기능과는 잘 동작하지 않을 수 있다.
예를 들어, 하나의 존에서 많은 트래픽이 발생하는 경우,
해당 존에 할당된 엔드포인트만 트래픽을 처리하고 있을 것이다.
이로 인해 {{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}가
이 이벤트를 감지하지 못하거나,
또는 새롭게 추가되는 파드가 다른 존에 추가될 수 있다.
## {{% heading "whatsnext" %}}
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어본다.

272
content/ko/docs/concepts/storage/ephemeral-volumes.md Normal file
View File

@ -0,0 +1,272 @@
---
title: 임시 볼륨
content_type: concept
weight: 30
---
<!-- overview -->
이 문서는 쿠버네티스의 _임시(ephemeral) 볼륨_ 에 대해 설명한다.
쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/),
특히 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 퍼시스턴트볼륨(PersistentVolume)에 대해 잘 알고 있는 것이 좋다.
<!-- body -->
일부 애플리케이션은 추가적인 저장소를 필요로 하면서도
재시작 시 데이터의 영구적 보존 여부는 신경쓰지 않을 수도 있다.
예를 들어, 캐싱 서비스는 종종 메모리 사이즈에 제약을 받으며
이에 따라 전반적인 성능에 적은 영향을 미치면서도
사용 데이터를 메모리보다는 느린 저장소에 간헐적으로 옮길 수도 있다.
또 다른 애플리케이션은 읽기 전용 입력 데이터를 파일에서 읽도록 되어 있으며,
이러한 데이터의 예시로는 구성 데이터 또는 비밀 키 등이 있다.
_임시 볼륨_ 은 이러한 사용 사례를 위해 설계되었다.
임시 볼륨은 파드의 수명을 따르며 파드와 함께 생성 및 삭제되기 때문에,
일부 퍼시스턴트 볼륨이 어디에서 사용 가능한지에 제약되는 일 없이
파드가 중지 및 재시작될 수 있다.
임시 볼륨은 파드 명세에 _인라인_ 으로 명시되며,
이로 인해 애플리케이션 배포 및 관리가 간편해진다.
### 임시 볼륨의 종류
쿠버네티스는 각 목적에 맞는
몇 가지의 임시 볼륨을 지원한다.
- [emptyDir](/ko/docs/concepts/storage/volumes/#emptydir):
파드가 시작될 때 빈 상태로 시작되며,
저장소는 로컬의 kubelet 베이스 디렉터리(보통 루트 디스크) 또는 램에서 제공된다
- [configMap](/ko/docs/concepts/storage/volumes/#configmap),
[downwardAPI](/ko/docs/concepts/storage/volumes/#downwardapi),
[secret](/ko/docs/concepts/storage/volumes/#secret):
각 종류의 쿠버네티스 데이터를 파드에 주입한다
- [CSI 임시 볼륨](#csi-ephemeral-volumes):
앞의 볼륨 종류와 비슷하지만,
특히 [이 기능을 지원](https://kubernetes-csi.github.io/docs/drivers.html)하는 특수한
[CSI 드라이버](https://github.com/container-storage-interface/spec/blob/master/spec.md)에 의해 제공된다
- [일반(generic) 임시 볼륨](#generic-ephemeral-volumes):
퍼시스턴트 볼륨도 지원하는 모든 스토리지 드라이버에 의해 제공될 수 있다
`emptyDir`, `configMap`, `downwardAPI`, `secret`은
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)로서
제공된다.
이들은 각 노드의 kubelet에 의해 관리된다.
CSI 임시 볼륨은
써드파티 CSI 스토리지 드라이버에 의해 제공 *되어야 한다*.
일반 임시 볼륨은 써드파티 CSI 스토리지 드라이버에 의해 제공 *될 수 있지만*,
동적 프로비저닝을 지원하는 다른 스토리지 드라이버에 의해서도 제공될 수 있다.
일부 CSI 드라이버는 특히 CSI 임시 볼륨을 위해 만들어져서
동적 프로비저닝을 지원하지 않는데,
이러한 경우에는 일반 임시 볼륨 용으로는 사용할 수 없다.
써드파티 드라이버 사용의 장점은
쿠버네티스 자체적으로는 지원하지 않는 기능(예:
kubelet에서 관리하는 디스크와 성능 특성이 다른 스토리지, 또는 다른 데이터 주입)을
제공할 수 있다는 것이다.
### CSI 임시 볼륨 {#csi-ephemeral-volumes}
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
이 기능을 사용하려면 `CSIInlineVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
쿠버네티스 1.16부터는 기본적으로 활성화되어 있다.
{{< note >}}
CSI 드라이버 중 일부만 CSI 임시 볼륨을 지원한다.
쿠버네티스 CSI [드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html)에서
어떤 드라이버가 임시 볼륨을 지원하는지 보여 준다.
{{< /note >}}
개념적으로, CSI 임시 볼륨은 `configMap`, `downwardAPI`, `secret` 볼륨 유형과 비슷하다.
즉, 스토리지는 각 노드에서 로컬하게 관리되며,
파드가 노드에 스케줄링된 이후에 다른 로컬 리소스와 함께 생성된다.
쿠버네티스에는 지금 단계에서는 파드를 재스케줄링하는 개념이 없다.
볼륨 생성은 실패하는 일이 거의 없어야 하며,
만약 실패할 경우 파드 시작 과정이 중단될 것이다.
특히, [스토리지 용량 인지 파드 스케줄링](/ko/docs/concepts/storage/storage-capacity/)은
이러한 볼륨에 대해서는 지원되지 *않는다*.
또한 이러한 볼륨은 파드의 스토리지 자원 사용 상한에 제한받지 않는데,
이는 kubelet 자신이 관리하는 스토리지에만 강제할 수 있는 것이기 때문이다.
다음은 CSI 임시 스토리지를 사용하는 파드에 대한 예시 매니페스트이다.
```yaml
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
command: [ "sleep", "1000000" ]
volumes:
- name: my-csi-inline-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:
foo: bar
```
`volumeAttributes`은 드라이버에 의해 어떤 볼륨이 준비되는지를 결정한다.
이러한 속성은 각 드라이버별로 다르며 표준화되지 않았다.
더 자세한 사항은 각 CSI 드라이버 문서를
참고한다.
클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며,
[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다.
### 일반 임시 볼륨 {#generic-ephemeral-volumes}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
일반 임시 볼륨은
프로비저닝 후 일반적으로 비어 있는 스크래치 데이터에 대해 파드 별 디렉터리를 제공한다는 점에서
`emptyDir` 볼륨과 유사하다.
하지만 다음과 같은 추가 기능도 제공한다.
- 스토리지는 로컬이거나 네트워크 연결형(network-attached)일 수 있다.
- 볼륨의 크기를 고정할 수 있으며 파드는 이 크기를 초과할 수 없다.
- 드라이버와 파라미터에 따라
볼륨이 초기 데이터를 가질 수도 있다.
- 볼륨에 대한 일반적인 작업은 드라이버가 지원하는 범위 내에서 지원된다.
이와 같은 작업은 다음을 포함한다.
[스냅샷](/ko/docs/concepts/storage/volume-snapshots/),
[복제](/ko/docs/concepts/storage/volume-pvc-datasource/),
[크기 조정](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장),
및 [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/).
다음은 예시이다.
```yaml
kind: Pod
apiVersion: v1
metadata:
name: my-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/scratch"
name: scratch-volume
command: [ "sleep", "1000000" ]
volumes:
- name: scratch-volume
ephemeral:
volumeClaimTemplate:
metadata:
labels:
type: my-frontend-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1Gi
```
### 라이프사이클 및 퍼시스턴트볼륨클레임
핵심 설계 아이디어는
[볼륨 클레임을 위한 파라미터](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)는
파드의 볼륨 소스 내부에서 허용된다는 점이다.
레이블, 어노테이션 및 퍼시스턴트볼륨클레임을 위한 모든 필드가 지원된다.
이러한 파드가 생성되면, 임시 볼륨 컨트롤러는 파드가 속한 동일한 네임스페이스에
퍼시스턴트볼륨클레임 오브젝트를 생성하고
파드가 삭제될 때에는 퍼시스턴트볼륨클레임도 삭제되도록 만든다.
이는 볼륨 바인딩 및/또는 프로비저닝을 유발하는데,
{{< glossary_tooltip text="스토리지클래스" term_id="storage-class" >}}가
즉각적인(immediate) 볼륨 바인딩을 사용하는 경우에는 즉시,
또는 파드가 노드에 잠정적으로 스케줄링되었을 때 발생한다(`WaitForFirstConsumer` 볼륨 바인딩 모드).
일반 임시 볼륨에는 후자가 추천되는데, 이 경우 스케줄러가 파드를 할당하기에 적합한 노드를 선택하기가 쉬워지기 때문이다.
즉각적인 바인딩을 사용하는 경우,
스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다.
[리소스 소유권](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 관점에서,
일반 임시 스토리지를 갖는 파드는
해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다.
파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데,
스토리지 클래스의 기본 회수 정책이 볼륨을 삭제하는 것이기 때문에 PVC의 삭제는 보통 볼륨의 삭제를 유발한다.
회수 정책을 `retain`으로 설정한 스토리지클래스를 사용하여 준 임시(quasi-ephemeral) 로컬 스토리지를 생성할 수도 있는데,
이렇게 하면 스토리지의 수명이 파드의 수명보다 길어지며,
이러한 경우 볼륨 정리를 별도로 수행해야 함을 명심해야 한다.
이러한 PVC가 존재하는 동안은, 다른 PVC와 동일하게 사용될 수 있다.
특히, 볼륨 복제 또는 스냅샷 시에 데이터 소스로 참조될 수 있다.
또한 해당 PVC 오브젝트는 해당 볼륨의 현재 상태도
가지고 있다.
### 퍼시스턴트볼륨클레임 이름 정하기
자동으로 생성된 PVC의 이름은 규칙에 따라 정해진다.
PVC의 이름은 파드 이름과 볼륨 이름의 사이를 하이픈(`-`)으로 결합한 형태이다.
위의 예시에서, PVC 이름은 `my-app-scratch-volume`가 된다.
이렇게 규칙에 의해 정해진 이름은 PVC와의 상호작용을 더 쉽게 만드는데,
이는 파드 이름과 볼륨 이름을 알면
PVC 이름을 별도로 검색할 필요가 없기 때문이다.
PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할 수
있으며("pod-a" 파드 + "scratch" 볼륨 vs. "pod" 파드 + "a-scratch" 볼륨 -
두 경우 모두 PVC 이름은 "pod-a-scratch")
또한 파드와 수동으로 생성한 PVC 간에도 이름 충돌이 발생할 수 있다.
이러한 충돌은 감지될 수 있는데, 이는 PVC가 파드를 위해 생성된 경우에만 임시 볼륨으로 사용되기 때문이다.
이러한 체크는 소유권 관계를 기반으로 한다.
기존에 존재하던 PVC는 덮어써지거나 수정되지 않는다.
대신에 충돌을 해결해주지는 않는데,
이는 적합한 PVC가 없이는 파드가 시작될 수 없기 때문이다.
{{< caution >}}
이러한 충돌이 발생하지 않도록
동일한 네임스페이스 내에서는 파드와 볼륨의 이름을 정할 때 주의해야 한다.
{{< /caution >}}
### 보안
GenericEphemeralVolume 기능을 활성화하면
사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며,
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다.
클러스터 관리자는 이를 명심해야 한다.
이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다.
- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우,
[파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를
사용한다(쿠버네티스
1.21에서 사용 중단됨).
- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을
사용한다.
일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로,
사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도,
다른 정책을 우회하는 데에는 사용할 수 없다.
## {{% heading "whatsnext" %}}
### kubelet이 관리하는 임시 볼륨
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)를 참고한다.
### CSI 임시 볼륨
- 설계에 대한 더 자세한 정보는
[임시 인라인 CSI 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)를 참고한다.
- 이 기능의 추가 개발에 대한 자세한 정보는 [enhancement 저장소의 이슈 #596](https://github.com/kubernetes/enhancements/issues/596)을 참고한다.
### 일반 임시 볼륨
- 설계에 대한 더 자세한 정보는
[일반 임시 인라인 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)를 참고한다.

42
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -73,8 +73,8 @@ API 서버 커맨드라인 플래그에 대한 자세한 정보는
일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 `volumes` 블록에 `persistentVolumeClaim`을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 [볼륨으로 클레임하기](#볼륨으로-클레임하기)를 참고하길 바란다.
### 사용 중인 스토리지 오브젝트 ​​보호
사용 중인 스토리지 오브젝트 ​​보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
### 사용 중인 스토리지 오브젝트 보호
사용 중인 스토리지 오브젝트 보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
{{< note >}}
PVC를 사용하는 파드 오브젝트가 존재하면 파드가 PVC를 사용하고 있는 상태이다.
@ -254,6 +254,16 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여
지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해
새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다.
{{< warning >}}
퍼시스턴트볼륨의 크기를 직접 변경하면 자동 볼륨 리사이즈 기능을 이용할 수 없게 된다.
퍼시스턴트볼륨의 크기를 변경하고,
퍼시스턴트볼륨에 해당되는 퍼시스턴트볼륨클레임의 `.spec`에 적혀 있는 크기를 동일하게 변경하면,
스토리지 리사이즈가 발생하지 않는다.
쿠버네티스 컨트롤 플레인은
두 리소스의 목표 상태(desired state)가 일치하는 것을 확인하고,
배후(backing) 볼륨 크기가 수동으로 증가되어 리사이즈가 필요하지 않다고 판단할 것이다.
{{< /warning >}}
#### CSI 볼륨 확장
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
@ -412,7 +422,7 @@ spec:
### 용량
일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 쿠버네티스 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)을 참고한다.
일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 용어집에 있는 [수량](/ko/docs/reference/glossary/?all=true#term-quantity) 항목을 참고한다.
현재 스토리지 용량 크기는 설정하거나 요청할 수 있는 유일한 리소스이다. 향후 속성에 IOPS, 처리량 등이 포함될 수 있다.
@ -525,19 +535,19 @@ PV는 `storageClassName` 속성을
다음 볼륨 유형은 마운트 옵션을 지원한다.
* AWSElasticBlockStore
* AzureDisk
* AzureFile
* CephFS
* Cinder (OpenStack 블록 스토리지)
* GCEPersistentDisk
* Glusterfs
* NFS
* Quobyte Volumes
* RBD (Ceph Block Device)
* StorageOS
* VsphereVolume
* iSCSI
* `awsElasticBlockStore`
* `azureDisk`
* `azureFile`
* `cephfs`
* `cinder` (v1.18에서 **사용 중단됨**)
* `gcePersistentDisk`
* `glusterfs`
* `iscsi`
* `nfs`
* `quobyte` (v1.22에서 **사용 중단됨**)
* `rbd`
* `storageos` (v1.22에서 **사용 중단됨**)
* `vsphereVolume`
마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.

4
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
parameters:
server: nfs-server.example.com
path: /share
readOnly: false
readOnly: "false"
```
* `server`: NFS 서버의 호스트네임 또는 IP 주소.
@ -797,7 +797,7 @@ parameters:
storagePool: sp1
storageMode: ThinProvisioned
secretRef: sio-secret
readOnly: false
readOnly: "false"
fsType: xfs
```

4
content/ko/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -39,6 +39,10 @@ weight: 41 # just after volume snapshots
처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
생성된 이후에는 업데이트할 수 없다.
{{< note >}}
CRD의 설치는 쿠버네티스 배포판의 책임이다. 필요한 CRD가 존재하지 않는다면, 볼륨스냅샷클래스 생성이 실패할 것이다.
{{< /note >}}
```yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass

9
content/ko/docs/concepts/storage/volumes.md
View File

@ -273,7 +273,7 @@ spec:
* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하기 위해서는
먼저 컨피그맵을 생성해야 한다.
* 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
* 컨피그맵을 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
업데이트를 수신하지 않는다.
* 텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩의 경우, `binaryData` 를 사용한다.
@ -285,7 +285,7 @@ spec:
이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다.
{{< note >}}
다운워드 API를 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API
다운워드 API를 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API
업데이트를 수신하지 않는다.
{{< /note >}}
@ -859,7 +859,7 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에
[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고
`CSIMigration`, `CSIMigrationRBD`
`CSIMigration`, `csiMigrationRBD`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
{{< note >}}
@ -894,7 +894,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
{{< /note >}}
{{< note >}}
시크릿을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿
시크릿을 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 시크릿
업데이트를 수신하지 못한다.
{{< /note >}}
@ -1133,6 +1133,7 @@ spec:
volumeMounts:
- name: workdir1
mountPath: /logs
# 변수 확장에는 괄호를 사용한다(중괄호 아님).
subPathExpr: $(POD_NAME)
restartPolicy: Never
volumes:

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

@ -70,7 +70,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
두 가지 개념이다.
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
* [가비지(Garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)은 _소유하는 리소스_ 가
제거된 후 클러스터에서 오브젝트를 정리한다.
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.

43
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -842,6 +842,13 @@ nginx-deployment-618515232 11 11 11 7m
* 디플로이먼트로 기존 레플리카셋을 스케일 다운.
* 새 파드가 준비되거나 이용할 수 있음(최소 [준비 시간(초)](#최소-대기-시간-초) 동안 준비됨).
롤아웃이 "진행 중" 상태가 되면,
디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
* `type: Progressing`
* `status: "True"`
* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated`
`kubectl rollout status` 를 사용해서 디플로이먼트의 진행사황을 모니터할 수 있다.
### 디플로이먼트 완료
@ -853,6 +860,17 @@ nginx-deployment-618515232 11 11 11 7m
* 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때.
* 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때.
롤아웃이 "완료" 상태가 되면,
디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
* `type: Progressing`
* `status: "True"`
* `reason: NewReplicaSetAvailable`
이 `Progressing` 컨디션은 새로운 롤아웃이 시작되기 전까지는 `"True"` 상태값을 유지할 것이다.
레플리카의 가용성이 변경되는 경우에도(이 경우 `Available` 컨디션에 영향을 미침)
컨디션은 유지된다.
`kubectl rollout status` 를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있다.
만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.
@ -890,7 +908,7 @@ echo $?
대기하는 시간(초)를 나타낸다.
다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가
10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
10분 후 디플로이먼트 롤아웃에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
```shell
kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
@ -902,14 +920,17 @@ deployment.apps/nginx-deployment patched
만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의
디플로이먼트 컨디션(DeploymentCondition)을 추가한다.
* Type=Progressing
* Status=False
* Reason=ProgressDeadlineExceeded
* `type: Progressing`
* `status: "False"`
* `reason: ProgressDeadlineExceeded`
이 컨디션은 일찍 실패할 수도 있으며 이러한 경우 `ReplicaSetCreateError`를 이유로 상태값을 `"False"`로 설정한다.
또한, 디플로이먼트 롤아웃이 완료되면 데드라인은 더 이상 고려되지 않는다.
컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다.
{{< note >}}
쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을
쿠버네티스는 `reason: ProgressDeadlineExceeded` 과 같은 상태 조건을
보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며,
예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다.
{{< /note >}}
@ -984,7 +1005,7 @@ Conditions:
디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나,
네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다.
만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면
성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`).
성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`status: "True"` 와 `reason: NewReplicaSetAvailable`).
```
Conditions:
@ -994,11 +1015,11 @@ Conditions:
Progressing True NewReplicaSetAvailable
```
`Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가
`type: Available` 과 `status: "True"` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `type: Progressing` 과 `status: "True"` 는 디플로이먼트가
롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다.
(자세한 내용은 특정 조건의 이유를 참조한다.
이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)
이 경우 `reason: NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)
`kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다.
`kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
@ -1153,8 +1174,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
### 진행 기한 시간(초)
`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의
상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `type: Progressing`, `status: "False"`의
상태 그리고 리소스가 `reason: ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다.
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다.
미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,

196
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
View File

@ -1,196 +0,0 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 60
---
<!-- overview -->
{{< note >}}
이 한글 문서는 더 이상 관리되지 않습니다.
이 문서의 기반이 된 영어 원문은 삭제되었으며,
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
이 문서는 삭제될 수 있습니다.
{{< /note >}}
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
<!-- body -->
## 소유자(owner)와 종속(dependent)
일부 쿠버네티스 오브젝트는 다른 오브젝트의 소유자이다. 예를 들어 레플리카셋은
파드 집합의 소유자이다. 소유자 오브젝트에게 소유된 오브젝트를 *종속*
이라고 한다. 모든 종속 오브젝트는 소유하는 오브젝트를 가르키는 `metadata.ownerReferences`
필드를 가지고 있다.
때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다.
예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의
`ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가
레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡
그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을
자동으로 설정한다.
또한 `ownerReference` 필드를 수동으로 설정해서 소유자와 종속 항목 간의
관계를 지정할 수도 있다.
여기에 파드 3개가 있는 레플리카셋의 구성 파일이 있다.
{{< codenew file="controllers/replicaset.yaml" >}}
레플리카셋을 생성하고 파드의 메타데이터를 본다면,
OwnerReferences 필드를 찾을 수 있다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
kubectl get pods --output=yaml
```
출력 결과는 파드의 소유자가 `my-repset` 이라는 이름의 레플리카셋인 것을 보여준다.
```yaml
apiVersion: v1
kind: Pod
metadata:
...
ownerReferences:
- apiVersion: apps/v1
controller: true
blockOwnerDeletion: true
kind: ReplicaSet
name: my-repset
uid: d9607e19-f88f-11e6-a518-42010a800195
...
```
{{< note >}}
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
종속 항목이 삭제될 수 있다.
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
이러한 종류의 이벤트를 확인할 수 있다.
{{< /note >}}
## 가비지 수집기의 종속 항목 삭제 방식 제어
오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의
여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading)
삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다.
만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면,
종속 항목은 *분리됨(orphaned)* 이라고 한다.
### 포어그라운드 캐스케이딩 삭제
*포어그라운드 캐스케이딩 삭제* 에서는 루트 오브젝트가 먼저
"삭제 중(deletion in progress)" 상태가 된다. "삭제 중" 상태에서는
다음 사항이 적용된다.
* 오브젝트는 REST API를 통해 여전히 볼 수 있음
* 오브젝트에 `deletionTimestamp` 가 설정됨
* 오브젝트의 "foregroundDeletion"에 `metadata.finalizers` 값이 포함됨.
"삭제 중" 상태가 설정되면, 가비지
수집기는 오브젝트의 종속 항목을 삭제한다. 가비지 수집기는 모든
"차단" 종속 항목(`ownerReference.blockOwnerDeletion=true` 가 있는 오브젝트)의 삭제가 완료되면,
소유자 오브젝트를 삭제한다.
"foregroundDeletion" 에서는 ownerReference.blockOwnerDeletion=true 로
설정된 종속 항목만 소유자 오브젝트의 삭제를 차단한다는 것을 참고한다.
쿠버네티스 버전 1.7에서는 소유자 오브젝트에 대한 삭제 권한에 따라 `blockOwnerDeletion` 를 true로 설정하기 위해 사용자 접근을 제어하는
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)가
추가되었기에 권한이 없는 종속 항목은 소유자 오브젝트의 삭제를 지연시킬 수 없다.
만약 오브젝트의 `ownerReferences` 필드가 컨트롤러(디플로이먼트 또는 레플리카셋과 같은)에
의해 설정된 경우 blockOwnerDeletion이 자동으로 설정되므로 이 필드를 수동으로 수정할 필요가 없다.
### 백그라운드 캐스케이딩 삭제
*백그라운드 캐스케이딩 삭제* 에서 쿠버네티스는 소유자 오브젝트를
즉시 삭제하고, 가비지 수집기는 백그라운드에서 종속 항목을
삭제한다.
### 캐스케이딩 삭제 정책 설정하기
캐스케이딩 삭제 정책을 제어하려면, 오브젝트를 삭제할 때 `deleteOptions`
인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
"Foreground" 또는 "Background" 이다.
여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
```
여기에 포어그라운드에서 종속 항목을 삭제하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
여기에 종속 항목을 분리됨으로 하는 예시가 있다.
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
kubectl도 캐스케이딩 삭제를 지원한다.
kubectl을 사용해서 포어그라운드의 종속 항목을 삭제하려면 `--cascade=foreground` 를 설정한다. 종속 항목을
분리하기 위해서는 `--cascade=orphan` 를 설정한다.
기본 동작은 백그라운드의 종속 항목을 삭제하는 것이며,
이는 `--cascade` 를 생략하거나 명시적으로 `background` 를 설정한 경우의 동작에 해당한다.
여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.
```shell
kubectl delete replicaset my-repset --cascade=false
```
### 디플로이먼트에 대한 추가 참고
1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
## 알려진 이슈들
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다.
## {{% heading "whatsnext" %}}
[디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)

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

@ -416,10 +416,10 @@ spec:
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
| [잡 템플릿 확장] | 1 | 1이어야 함 |
[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/
[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/
[작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/
[가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/
[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
## 고급 사용법
@ -615,8 +615,8 @@ spec:
```
새 잡 자체는 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 와 다른 uid 를 가지게 될 것이다.
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
불일치를 허용한다.
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있으며
이런 불일치를 허용한다고 알릴 수 있다.
### 종료자(finalizers)를 이용한 잡 추적

4
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -26,7 +26,7 @@ weight: 20
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
사용한다.
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/architecture/garbage-collection/#소유자-owner-와-종속-dependent)
필드를 통해 파드에 연결되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
@ -269,7 +269,7 @@ matchLabels:
### 레플리카셋과 해당 파드 삭제
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/architecture/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
설정해야 한다.

2
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -405,7 +405,7 @@ spec:
* [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
스테이트풀셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.

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

@ -117,7 +117,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는
두 가지 종류의 공유 ​​리소스를 제공한다.
두 가지 종류의 공유 리소스를 제공한다.
## 파드 작업

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

@ -58,7 +58,7 @@ graph TB
class zoneA,zoneB cluster;
{{< /mermaid >}}
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘 알려진 레이블](/ko/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
## 파드의 분배 제약 조건

8
content/ko/docs/contribute/advanced.md
View File

@ -110,15 +110,13 @@ SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/
## SIG 공동 의장으로 봉사
SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는
SIG Docs의 공동 의장 역할을 할 수 있다.
### 전제 조건
승인자는 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.
쿠버네티스 멤버가 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.
- 6개월 이상 SIG Docs 승인자로 활동한다.
- [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다.
- SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트).
- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
[k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs),
@ -126,6 +124,8 @@ SIG Docs의 공동 의장 역할을 할 수 있다.
[SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의
역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는
영향을 이해한다.
추가로, [쿠버네티스 문서 릴리스 프로세스](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정)가 어떻게 동작하는지 이해한다.
- SIG Docs 커뮤니티에 이해 직접적으로 또는 lazy consensus(특정 기간 내에 아무런 의견이 없으면 통과)를 통해 승인된다.
- 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다.
### 책임

2
content/ko/docs/contribute/generate-ref-docs/quickstart.md
View File

@ -114,7 +114,7 @@ repos:
`generate-command` 필드의 내용은 수정하지 말아야 한다.
대부분의 경우 `reference.yml` 을 직접 수정해야 할 필요는 없다.
때때로, 업스트림 소스코드 업데이트 때문에 이 환경설정 파일을 수정해야 할 수도 있다.
(예: Golang 버전 의존성, 서드파티 라이브러리 변경 등)
(예: Golang 버전 의존성, 써드파티 라이브러리 변경 등)
만약 스크립트 사용 시 빌드 문제가 있다면,
[쿠버네티스 슬랙의 #sig-docs 채널](https://kubernetes.slack.com/archives/C1J0BPD2M)에서 SIG-Docs 팀에 문의하면 된다.

9
content/ko/docs/contribute/participate/roles-and-responsibilities.md
View File

@ -51,7 +51,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.
{{< note >}}
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, "LGTM" 코멘트를 남기는 것도 좋다!
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면,
"LGTM" 코멘트를 남기는 것도 좋다!
{{< /note >}}
- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
@ -89,7 +90,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다.
축하한다!
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다.
피드백의 내용을 해결한 후, 다시 지원하자.
1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.
@ -138,7 +140,8 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
### 리뷰어 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
충족하면, SIG Docs 리뷰어가 될 수 있다.
다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
반드시 별도로 지원해야 한다.
지원하려면, 다음을 수행한다.

4
content/ko/docs/contribute/review/for-approvers.md
View File

@ -72,14 +72,14 @@ PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는
풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는
챗봇 스타일 명령으로 쿠버네티스
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 ​​있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다.
{{< table caption="리뷰를 위한 Prow 명령" >}}
Prow 명령 | 역할 제한 | 설명
:------------|:------------------|:-----------
`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
`/lgtm` | 조직 멤버 | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
`/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다.
`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다.
`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다.

6
content/ko/docs/contribute/review/reviewing-prs.md
View File

@ -85,7 +85,11 @@ class third,fourth white
- PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
- 다른 리뷰어의 의견 읽기
- **Files changed** 탭을 클릭하여 변경된 파일과 행 보기
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 Netlify 미리보기 빌드의 변경 사항을 확인.
다음은 스크린샷이다(GitHub 데스크탑 사이트이며,
태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다).
{{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="Netlify 미리보기 링크를 포함하는 GitHub PR 상세 사항" >}}
미리보기를 열려면, 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다.
4. **Files changed** 탭으로 이동하여 리뷰를 시작한다.
1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.

2
content/ko/docs/contribute/style/write-new-topic.md
View File

@ -24,7 +24,7 @@ weight: 20
타입 | 설명
:--- | :----------
개념 | 개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 <a href="/ko/docs/concepts/architecture/nodes/">노드</a>를 참조하자.
태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/ko/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
{{< /table >}}

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

@ -26,7 +26,7 @@ no_list: true
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/)
* [잘 알려진 레이블, 어노테이션과 테인트](/ko/docs/reference/labels-annotations-taints/)
## 공식적으로 지원되는 클라이언트 라이브러리
@ -73,14 +73,16 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kube-apiserver 환경설정 (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/)
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
* [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
* [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
[kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
[kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및
[클라이언트 인증 API (v1)](/docs/reference/config-api/client-authentication.v1/)
* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
## kubeadm을 위한 API 설정

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

@ -25,7 +25,8 @@ card:
각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을
활성화 또는 비활성화할 수 있다.
모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다.
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
```shell
--feature-gates="...,GracefulNodeShutdown=true"
@ -53,7 +54,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|---------|---------|-------|-------|-------|
| `APIListChunking` | `false` | 알파 | 1.8 | 1.8 |
| `APIListChunking` | `true` | 베타 | 1.9 | |
| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 |
| `APIPriorityAndFairness` | `false` | 알파 | 1.18 | 1.19 |
| `APIPriorityAndFairness` | `true` | 베타 | 1.20 | |
| `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | 베타 | 1.16 | |
@ -65,7 +66,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | |
| `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | |
| `CPUManagerPolicyBetaOptions` | `true` | 베타 | 1.23 | |
| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | 1.22 |
| `CPUManagerPolicyOptions` | `true` | 베타 | 1.23 | |
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
@ -85,13 +89,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | |
| `CSIMigrationRBD` | `false` | 알파 | 1.23 | |
| `csiMigrationRBD` | `false` | 알파 | 1.23 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
| `CSRDuration` | `true` | 베타 | 1.22 | |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
@ -100,12 +102,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | |
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 |
| `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | |
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
| `DevicePlugins` | `true` | 베타 | 1.10 | |
| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
| `DisableCloudProviders` | `false` | 알파 | 1.22 | |
| `DisableKubeletCloudCredentialProviders` | `false` | 알파 | 1.23 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
@ -124,7 +128,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | |
| `GRPCContainerProbe` | `false` | 알파 | 1.23 | |
| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `IdentifyPodOS` | `false` | 알파 | 1.23 | |
@ -135,6 +141,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginPortworxUnregister` | `false` | 알파 | 1.23 | |
| `InTreePluginRBDUnregister` | `false` | 알파 | 1.23 | |
| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
| `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | |
| `JobReadyPods` | `false` | 알파 | 1.23 | |
@ -142,7 +150,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 |
| `KubeletPodResourcesGetAllocatable` | `false` | 베타 | 1.23 | |
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
@ -157,10 +168,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `NodeSwap` | `false` | 알파 | 1.22 | |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
| `OpenAPIEnums` | `false` | 알파 | 1.23 | |
| `OpenAPIV3` | `false` | 알파 | 1.23 | |
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | |
| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 |
@ -189,6 +203,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
| `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | |
| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 |
| `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | |
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
@ -197,13 +212,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
| `SuspendJob` | `true` | 베타 | 1.22 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | 1.22 |
| `TopologyAwareHints` | `true` | 베타 | 1.23 | |
| `TopologyAwareHints` | `false` | 베타 | 1.23 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
| `WinDSR` | `false` | 알파 | 1.14 | |
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 |
| `WindowsHostProcessContainers` | `false` | 베타 | 1.23 | |
{{< /table >}}
@ -233,6 +249,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 |
| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 |
| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
@ -312,12 +330,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 |
| `EndpointSliceProxying` | `true` | GA | 1.22 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
| `EvenPodsSpread` | `true` | GA | 1.19 | - |
| `ExecProbeTimeout` | `true` | GA | 1.20 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
@ -330,9 +348,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `HugePages` | `false` | 알파 | 1.8 | 1.9 |
| `HugePages` | `true` | 베타| 1.10 | 1.13 |
| `HugePages` | `true` | GA | 1.14 | - |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
@ -351,9 +366,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 |
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
| `KubeletPodResources` | `true` | GA | 1.20 | |
| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
@ -375,7 +387,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 |
| `PodDisruptionBudget` | `true` | GA | 1.21 | - |
@ -497,7 +508,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 |
| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 |
| `WindowsGMSA` | `true` | GA | 1.18 | - |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 |
| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 |
| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 |
| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
@ -553,7 +563,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
- `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다.
- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는
플러그인의 초기 형태를 제공하였으며, 사용 중단되었다.
대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
확인한다.
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
설정을 활성화한다.
@ -562,8 +575,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
TLS 확인을 건너뛸 수 있도록 한다.
- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의
`DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다.
- `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
- `AppArmor`: 리눅스 노드에서 실행되는 파드에 대한 AppArmor 필수 접근 제어의 사용을 활성화한다.
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다.
- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
대한 제한을 보고하도록 한다.
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
@ -586,6 +599,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
리더 마이그레이션(Leader Migration)을 활성화한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다.
이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다.
이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다.
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다.
이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다.
이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다.
- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
@ -638,9 +657,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
지원한다. CSIMigration 기능 플래그가 필요하다.
- `CSIMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
클러스터에 CSIMigration 및 CSIMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는
`InTreePluginRBDUnregister` 기능 플래그에 의해
@ -716,6 +735,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
데몬셋 워크로드를 사용하도록 설정한다.
[데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다.
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
@ -728,6 +748,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
모든 기능을 비활성화한다.
- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해
클라우드 프로바이더 컨테이너 레지스트리에 인증을 수행하는 kubelet 내부(in-tree) 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
hugepages 사용을 활성화한다.
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
@ -768,6 +790,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
kubelet과 kube-apiserver를 사용하도록 설정한다.
이 기능을 사용하려면 컨테이너 런타임이 지원해야 한다(Containerd: v1.5.6 이상, CRI-O: v1.22 이상).
[확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
@ -792,7 +815,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
[Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을
참조한다.
- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때
kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다.
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
- `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
개별 컨테이너 메트릭을 기반으로 확장한다.
- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
@ -818,6 +844,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
플러그인의 등록을 중지한다.
- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
@ -889,6 +919,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의
"enum" 필드 채우기를 활성화한다.
- `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,

2
content/ko/docs/reference/glossary/aggregation-layer.md
View File

@ -2,7 +2,7 @@
title: 애그리게이션 레이어(Aggregation Layer)
id: aggregation-layer
date: 2018-10-08
full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
full_link: /ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
short_description: >
애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다.

2
content/ko/docs/reference/glossary/configmap.md
View File

@ -2,7 +2,7 @@
title: 컨피그맵(ConfigMap)
id: configmap
date: 2018-04-12
full_link: /docs/concepts/configuration/configmap/
full_link: /ko/docs/concepts/configuration/configmap/
short_description: >
키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다.

10
content/ko/docs/reference/glossary/container-runtime.md
View File

@ -2,7 +2,7 @@
title: 컨테이너 런타임
id: container-runtime
date: 2019-06-05
full_link: /docs/setup/production-environment/container-runtimes
full_link: /ko/docs/setup/production-environment/container-runtimes/
short_description: >
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
@ -15,7 +15,7 @@ tags:
<!--more-->
쿠버네티스는 여러 컨테이너 런타임을 지원한다. {{< glossary_tooltip term_id="docker">}},
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}
그리고 [Kubernetes CRI (컨테이너 런타임
인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
쿠버네티스는 {{< glossary_tooltip term_id="containerd" >}},
{{< glossary_tooltip term_id="cri-o" >}}와 같은 컨테이너 런타임 및
모든 [Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
구현체를 지원한다.

2
content/ko/docs/reference/glossary/device-plugin.md
View File

@ -2,7 +2,7 @@
title: 장치 플러그인(Device Plugin)
id: device-plugin
date: 2019-02-02
full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
short_description: >
파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장
aka:

22
content/ko/docs/reference/glossary/garbage-collection.md Normal file
View File

@ -0,0 +1,22 @@
---
title: 가비지(Garbage) 수집
id: garbage-collection
date: 2022-01-14
full_link: /ko/docs/concepts/architecture/garbage-collection/
short_description: >
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
aka:
tags:
- fundamental
- operation
---
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
<!--more-->
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
[실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
[타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/),
[종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고
만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다.

2
content/ko/docs/reference/glossary/job.md
View File

@ -2,7 +2,7 @@
title: 잡(Job)
id: job
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/job
full_link: /ko/docs/concepts/workloads/controllers/job/
short_description: >
완료를 목표로 실행되는 유한 또는 배치 작업.

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

@ -2,7 +2,7 @@
title: kube-proxy
id: kube-proxy
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
full_link: /ko/docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.

2
content/ko/docs/reference/glossary/limitrange.md
View File

@ -2,7 +2,7 @@
title: 범위 제한(LimitRange)
id: limitrange
date: 2019-04-15
full_link: /docs/concepts/policy/limit-range/
full_link: /ko/docs/concepts/policy/limit-range/
short_description: >
네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.

2
content/ko/docs/reference/glossary/logging.md
View File

@ -2,7 +2,7 @@
title: 로깅(Logging)
id: logging
date: 2019-04-04
full_link: /docs/concepts/cluster-administration/logging/
full_link: /ko/docs/concepts/cluster-administration/logging/
short_description: >
로그는 클러스터나 애플리케이션에 의해 로깅된 이벤트의 목록이다.

2
content/ko/docs/reference/glossary/network-policy.md
View File

@ -2,7 +2,7 @@
title: 네트워크 폴리시(Network Policy)
id: network-policy
date: 2018-04-12
full_link: /docs/concepts/services-networking/network-policies/
full_link: /ko/docs/concepts/services-networking/network-policies/
short_description: >
파드 그룹들이 서로에 대한 그리고 다른 네트워크 엔드포인트에 대한 통신이 어떻게 허용되는지에 대한 명세이다.

2
content/ko/docs/reference/glossary/pod-security-policy.md
View File

@ -2,7 +2,7 @@
title: 파드 시큐리티 폴리시(Pod Security Policy)
id: pod-security-policy
date: 2018-04-12
full_link: /docs/concepts/policy/pod-security-policy/
full_link: /ko/docs/concepts/policy/pod-security-policy/
short_description: >
파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.

2
content/ko/docs/reference/glossary/resource-quota.md
View File

@ -2,7 +2,7 @@
title: 리소스 쿼터(Resource Quotas)
id: resource-quota
date: 2018-04-12
full_link: /docs/concepts/policy/resource-quotas/
full_link: /ko/docs/concepts/policy/resource-quotas/
short_description: >
네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공한다.

2
content/ko/docs/reference/glossary/service.md
View File

@ -2,7 +2,7 @@
title: 서비스(Service)
id: service
date: 2018-04-12
full_link: /docs/concepts/services-networking/service/
full_link: /ko/docs/concepts/services-networking/service/
short_description: >
네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법

2
content/ko/docs/reference/glossary/static-pod.md
View File

@ -2,7 +2,7 @@
title: 스태틱 파드(Static Pod)
id: static-pod
date: 2019-02-12
full_link: /docs/tasks/configure-pod-container/static-pod/
full_link: /ko/docs/tasks/configure-pod-container/static-pod/
short_description: >
특정 노드의 Kubelet 데몬이 직접 관리하는 파드

2
content/ko/docs/reference/glossary/taint.md
View File

@ -2,7 +2,7 @@
title: 테인트(Taint)
id: taint
date: 2019-01-11
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.

2
content/ko/docs/reference/glossary/toleration.md
View File

@ -2,7 +2,7 @@
title: 톨러레이션(Toleration)
id: toleration
date: 2019-01-11
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
short_description: >
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.

23
content/ko/docs/reference/kubectl/conventions.md
View File

@ -31,29 +31,6 @@ content_type: concept
`--dry-run` 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
{{< note >}}
모든 `kubectl run`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
{{< /note >}}
#### 생성기
`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.
* `clusterrole`: 클러스터롤(ClusterRole)를 생성한다.
* `clusterrolebinding`: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
* `configmap`: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
* `cronjob`: 지정된 이름으로 크론잡(CronJob)을 생성한다.
* `deployment`: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
* `job`: 지정된 이름으로 잡(Job)을 생성한다.
* `namespace`: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
* `poddisruptionbudget`: 지정된 이름으로 PodDisruptionBudget을 생성한다.
* `priorityclass`: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
* `quota`: 지정된 이름으로 쿼터(Quota)를 생성한다.
* `role`: 단일 규칙으로 롤(Role)을 생성한다.
* `rolebinding`: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
* `secret`: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
* `service`: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
* `serviceaccount`: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
### `kubectl apply`
* `kubectl apply`를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 [Kubectl 책](https://kubectl.docs.kubernetes.io)을 참고한다.

14
content/ko/docs/reference/labels-annotations-taints.md
View File

@ -159,6 +159,20 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클
`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다.
`PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다.
## volume.beta.kubernetes.io/storage-provisioner (사용 중단됨)
예시: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath`
적용 대상: PersistentVolumeClaim
이 어노테이션은 사용 중단되었다.
## volume.kubernetes.io/storage-provisioner
적용 대상: PersistentVolumeClaim
이 어노테이션은 동적 프로비저닝이 요구되는 PVC에 추가될 예정이다.
## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
예시: `node.kubernetes.io/windows-build=10.0.17763`

1
content/ko/docs/reference/scheduling/policies.md
View File

@ -17,4 +17,3 @@ sitemap:
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기

19
content/ko/docs/reference/tools/_index.md
View File

@ -12,16 +12,17 @@ no_list: true
<!-- body -->
## Minikube
## crictl
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
실행하는 도구이다.
[`crictl`](https://github.com/kubernetes-sigs/cri-tools)은
{{<glossary_tooltip term_id="cri" text="CRI">}}-호환 컨테이너 런타임의 조사 및 디버깅을 위한
명령줄 인터페이스이다.
## 대시보드
[`대시보드`](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/), 는 쿠버네티스의 웹기반 유저 인터페이스이며 컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고
클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.
[`대시보드`](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는
쿠버네티스의 웹기반 유저 인터페이스이며
컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고 클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해 준다.
## Helm
{{% thirdparty-content single="true" %}}
@ -65,3 +66,9 @@ Kui를 사용하면 다음의 작업이 가능하다.
* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여
실행 형상을 워터폴 그림으로 확인한다.
* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다.
## Minikube
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
실행하는 도구이다.

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

@ -67,6 +67,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
| PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
| Python | [github.com/gtsystem/lightkube](https://github.com/gtsystem/lightkube) |
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |

4
content/ko/docs/setup/best-practices/certificates.md
View File

@ -1,5 +1,7 @@
---
title: PKI 인증서 및 요구 사항
content_type: concept
weight: 40
---
@ -75,7 +77,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
| 기본 CN | 부모 CA | O (주체에서) | 종류 | 호스트 (SAN) |
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` |
| kube-etcd | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-healthcheck-client | etcd-ca | | client | |
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |

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

@ -15,12 +15,19 @@ weight: 20
<!-- body -->
쿠버네티스 {{< skew currentVersion >}}에서는
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
런타임을 사용해야 한다.
더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다.
이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한
세부 정보가 있다.
- [containerd](#containerd)
- [CRI-O](#cri-o)
- [도커](#도커)
- [도커 엔진](#docker)
- [미란티스 컨테이너 런타임](#mcr)
{{< note >}}
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
@ -76,13 +83,17 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명
추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
```shell
# dnf install -y grubby && \
# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다.
# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해
# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다.
sudo dnf install -y grubby && \
sudo grubby \
--update-kernel=ALL \
--args="systemd.unified_cgroup_hierarchy=1"
```
구성을 적용하려면 노드를 재부팅해야 한다.
커널이 사용하는 커맨드 라인을 업데이트하려면,
변경 사항을 적용하기 위해 노드를 재시작해야 한다.
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
@ -94,13 +105,24 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
## CRI 버전 지원 {#cri-versions}
사용할 컨테이너 런타임이 적어도 CRI의 v1alpha2 이상을 지원해야 한다.
쿠버네티스 {{< skew currentVersion >}} 버전에서는 기본적으로 CRI API 중 v1을 사용한다.
컨테이너 런타임이 v1 API를 지원하지 않으면,
kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된다.
## 컨테이너 런타임
{{% thirdparty-content %}}
### containerd
이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
다음 명령을 사용하여 시스템에 containerd를 설치한다.
필수 구성 요소를 설치 및 구성한다.
@ -151,13 +173,12 @@ containerd를 설치한다.
{{% tab name="Windows (PowerShell)" %}}
PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다.
설정(예: `$Version:"1.4.3"`)한 후 다음 명령을 실행한다.
1. containerd 다운로드
```powershell
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.
gz
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz
```
@ -393,44 +414,28 @@ cgroup_manager = "cgroupfs"
CRI-O의 cgroup 드라이버 구성을 동기화 상태로
유지해야 한다.
### 도커
### 도커 엔진 {#docker}
1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라
리눅스 배포판용 도커를 설치한다.
이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서
검증된 최신 버전의 도커를 찾을 수 있다.
도커 엔진은 모든 것을 시작한 컨테이너 런타임이다.
이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다.
[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서
이 런타임 설치의 옵션들을 확인할 수 있다.
2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.
도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다.
더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다.
```shell
sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
```
지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 통해
쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는
써드파티 어댑터를 찾아볼 수도 있다.
{{< note >}}
`overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL
또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
{{< /note >}}
다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다.
3. 도커 재시작과 부팅시 실행되게 설정
- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
```shell
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker
```
### 미란티스 컨테이너 런타임 {#mcr}
{{< note >}}
더 자세한 내용은
- [도커 데몬 설정](https://docs.docker.com/config/daemon/)
- [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/)
{{< /note >}}
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
이전에는 도커 엔터프라이즈 에디션으로 알려져 있었다.
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
이 컴포넌트는 MCR에 포함되어 있다.

2
content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
View File

@ -144,7 +144,6 @@ Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
patches:
directory: /home/user/somedir
```
@ -159,7 +158,6 @@ nodeRegistration:
```yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
nodeRegistration:
patches:
directory: /home/user/somedir
```

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

@ -702,7 +702,7 @@ kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을
* 시크릿에 대한 하위 경로 볼륨 마운트
* 호스트 마운트 프로젝션
* DefaultMode(UID/GID 종속성에 기인함)
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 ​​읽기 전용을 지원한다.
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 읽기 전용을 지원한다.
* 블록 디바이스 매핑
* 저장 매체로서의 메모리
* uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
@ -763,7 +763,7 @@ DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /
파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로
소스로 다시 라우팅되지 않는다.
* TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에
* TCP/UDP 패킷은 여전히 치환될 수 있기 때문에
`ping <destination>`을 `curl <destination>`으로 대체하여
외부와의 연결을 디버깅할 수 있다.

2
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -309,4 +309,4 @@ spec:
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
[RuntimeClass]: https://kubernetes.io/ko/docs/concepts/containers/runtime-class/

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

@ -214,7 +214,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
## 클러스터에서 실행되는 서비스로 접근
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
## redirect 요청하기

4
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
View File

@ -218,8 +218,8 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
#### 워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고
각각의 워크로드 종류는 따로 보여진다.
해당 뷰는 애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여준다.
각각의 워크로드 종류는 분리하여 볼 수 있다.
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
워크로드에 대한 실용적인 정보를 요약한다.

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