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

Merge pull request #27589 from pjhwa/outdated1-27490 

[ko] Update outdated files in dev-1.21-ko.1 (p5)
This commit is contained in:
Kubernetes Prow Robot 2021-04-26 18:27:04 -07:00 committed by GitHub
parent d9136417cd 6338d1b811
commit 4203b524b8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
36 changed files with 644 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/docs/concepts/architecture/cloud-controller.md
View File

@ -206,6 +206,8 @@ rules:
[클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는
클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다.
클라우드 컨트롤러 매니저를 사용하기 위해 HA 컨트롤 플레인을 업그레이드하려면, [클라우드 컨트롤러 매니저를 사용하기 위해 복제된 컨트롤 플레인 마이그레이션 하기](/docs/tasks/administer-cluster/controller-manager-leader-migration/)를 참고한다.
자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?
클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다.

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

@ -8,14 +8,15 @@ aliases:
<!-- overview -->
이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
<!-- body -->
## 노드에서 컨트롤 플레인으로의 통신
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@ -50,20 +51,20 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
### API 서버에서 노드, 파드 및 서비스로의 통신
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
### SSH 터널
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
### Konnectivity 서비스
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

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

@ -63,6 +63,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
노드 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
### 노드 이름 고유성
[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
업데이트 후 다시 추가해야 한다.
### 노드에 대한 자체-등록
kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
@ -233,6 +243,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
#### 하트비트
@ -273,6 +284,7 @@ ConditionFalse 다.).
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@ -329,14 +341,27 @@ ConditionFalse 다.).
자세한 내용은
[노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
## 그레이스풀(Graceful) 노드 셧다운
## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다.
`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다.
Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다.
그레이스풀 노드 셧다운 기능은
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를
사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다.
그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 `GracefulNodeShutdown`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 제어된다.
기본적으로, 아래 설명된 두 구성 옵션,
`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
@ -345,9 +370,13 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
## {{% heading "whatsnext" %}}

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

@ -16,6 +16,7 @@ content_type: concept
## 네트워킹과 네트워크 폴리시
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.

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

@ -83,12 +83,15 @@ kubectl logs counter
[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. kubelet은
이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. 두 개의 kubelet 플래그 `container-log-max-size` 및 `container-log-max-files` 를 사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
실행하면, 노드의 kubelet이 요청을 처리하고
로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다.
{{< note >}}
만약, 일부 외부 시스템이 로테이션을 수행한 경우,
만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우,
`kubectl logs` 를 통해 최신 로그 파일의 내용만
사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가
로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일)

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

@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled
```
먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다.
방금 레이블을 지정한 파드를 보려면, 다음을 실행한다.
레이블을 지정한 파드를 보려면, 다음을 실행한다.
```shell
kubectl get pods -l app=nginx -L tier

6
content/ko/docs/concepts/cluster-administration/proxies.md
View File

@ -39,7 +39,7 @@ weight: 90
- UDP, TCP, SCTP를 이용하여 프락시 한다.
- HTTP는 이해하지 못한다.
- 로드 밸런싱을 제공한다.
- 단지 서비스에 도달하는데 사용한다.
- 서비스에 도달하는데만 사용한다.
1. API 서버 앞단의 프락시/로드밸런서
@ -61,7 +61,3 @@ weight: 90
## 요청을 리다이렉트하기
프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다.

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

@ -130,7 +130,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
### kube-scheduler 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
@ -148,6 +148,24 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
## 메트릭 비활성화
커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`).
## 메트릭 카디널리티(cardinality) 적용
제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다.
알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다.
각 매핑은 `<metric_name>,<label_name>=<allowed_labels>` 형식이다. 여기서
`<allowed_labels>` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다.
전체 형식은 다음과 같다.
`--allow-label-value <metric_name>,<label_name>='<allow_value1>, <allow_value2>...', <metric_name2>,<label_name>='<allow_value1>, <allow_value2>...', ...`.
예시는 다음과 같다.
`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'`
## {{% heading "whatsnext" %}}

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

@ -223,7 +223,7 @@ spec:
현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
캐시 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
모든 요청을 리디렉션할 수 있다.
@ -233,11 +233,12 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과
컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
데이터 변경을 방지하면 다음과 같은 이점이 있다.

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

@ -21,9 +21,6 @@ feature:
컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을
예약한다.
<!-- body -->
## 요청 및 제한
@ -72,7 +69,7 @@ Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
이것은 `memory` 및 `cpu` 리소스와는 다르다.
{{< /note >}}
CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트
CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 한다. 컴퓨트
리소스는 요청, 할당 및 소비될 수 있는 측정 가능한
수량이다. 이것은
[API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
@ -441,7 +438,9 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다.
* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
* [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의
`featureGates` 필드 또는 `--feature-gates` 커맨드 라인 플래그를 사용하여
`LocalStorageCapacityIsolationFSQuotaMonitoring=true`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화한다.
@ -449,6 +448,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다.
ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터
추적 기능을 활성화해야 한다.
```bash
# ext4인 /dev/block-device가 마운트되지 않은 경우
sudo tune2fs -O project -Q prjquota /dev/block-device
@ -518,9 +518,8 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.
[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서
스케줄러 익스텐더가
처리하는 확장된 리소스를 지정할 수 있다.
[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.
**예제:**
@ -743,23 +742,13 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
컨테이너가 `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 레퍼런스 읽어보기
* 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/)에 대해 더 읽어보기

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

@ -109,7 +109,7 @@ empty-secret Opaque 0 2m6s
```
해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다.
이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다.
이 경우, `0` 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다.
### 서비스 어카운트 토큰 시크릿
@ -667,7 +667,7 @@ cat /etc/foo/password
볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
캐시의 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접
리디렉션하여 전파할 수 있다.
@ -749,9 +749,9 @@ echo $SECRET_PASSWORD
## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은
개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
다음과 같은 이점이 있다.
@ -760,8 +760,8 @@ echo $SECRET_PASSWORD
- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
크게 줄임으로써 클러스터의 성능을 향상시킴
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
의해 제어된다. `immutable` 필드를 `true` 로 설정하여
변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다.
```yaml
@ -865,6 +865,7 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT
### 사용 사례: 컨테이너 환경 변수로 사용하기
시크릿 정의를 작성한다.
```yaml
apiVersion: v1
kind: Secret
@ -877,6 +878,7 @@ data:
```
시크릿을 생성한다.
```shell
kubectl apply -f mysecret.yaml
```
@ -1173,14 +1175,12 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,
시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을
수행해야 한다. 이를 통해 관리자는 앱에 필요한
[개별 인스턴스에 대한 접근을 허용 목록에 추가](
/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
[개별 인스턴스에 대한 접근을 허용 목록에 추가](/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
제한할 수 있다.
`get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
있을 것이다.

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

@ -50,10 +50,11 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
### 훅 핸들러 구현
컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
* Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
* HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
### 훅 핸들러 실행

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

@ -44,7 +44,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
커스텀 리소스와 결합할 때 특히 효과적이다.
[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의
[오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)은 사용자 정의
리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을
쿠버네티스 API의 익스텐션으로 인코딩할 수 있다.

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

@ -192,10 +192,69 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고,
// PodResourcesLister는 kubelet에서 제공하는 서비스로, 노드의 포드 및 컨테이너가
// 사용한 노드 리소스에 대한 정보를 제공한다.
service PodResourcesLister {
rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
}
```
`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
실행 중인 파드의 리소스에 대한 정보를 제공한다.
```gRPC
// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
message ListPodResourcesResponse {
repeated PodResources pod_resources = 1;
}
// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
message PodResources {
string name = 1;
string namespace = 2;
repeated ContainerResources containers = 3;
}
// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
message ContainerResources {
string name = 1;
repeated ContainerDevices devices = 2;
repeated int64 cpu_ids = 3;
}
// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
message TopologyInfo {
repeated NUMANode nodes = 1;
}
// NUMA 노드의 NUMA 표현
message NUMANode {
int64 ID = 1;
}
// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
message ContainerDevices {
string resource_name = 1;
repeated string device_ids = 2;
TopologyInfo topology = 3;
}
```
GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다.
kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다.
```gRPC
// AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다.
message AllocatableResourcesResponse {
repeated ContainerDevices devices = 1;
repeated int64 cpu_ids = 2;
}
```
`ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은
[kubelet에 등록할 때](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) 장치 플러그인이 보고하는 것과 일치한다.
gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
@ -204,7 +263,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
`PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
## 토폴로지 관리자와 장치 플러그인 통합

5
content/ko/docs/concepts/overview/components.md
View File

@ -30,8 +30,9 @@ card:
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면
[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다.
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
실행되는 컨트롤 플레인 설정의 예제를 보려면
[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.
### kube-apiserver

7
content/ko/docs/concepts/overview/working-with-objects/names.md
View File

@ -21,11 +21,15 @@ weight: 20
{{< glossary_definition term_id="name" length="all" >}}
{{< note >}}
물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
{{< /note >}}
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
@ -83,4 +87,3 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.

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

@ -26,7 +26,7 @@ weight: 30
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을
구별하기 위해 {{< glossary_tooltip text="레이블" term_id="label" >}}을
사용한다.
## 네임스페이스 다루기
@ -109,6 +109,16 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
## 자동 레이블링
{{< feature-state state="beta" for_k8s_version="1.21" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화된 경우 모든 네임스페이스에 변경할 수 없는(immutable) {{< glossary_tooltip text="레이블" term_id="label" >}}
`kubernetes.io / metadata.name` 을 설정한다.
레이블 값은 네임스페이스 이름이다.
## {{% heading "whatsnext" %}}
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.

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

@ -9,7 +9,9 @@ weight: 30
<!-- overview -->
{{< feature-state state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다.
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.

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

@ -124,6 +124,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. |
| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. |
{{< note >}}
CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. 이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. 자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다.
{{< /note >}}
## 오브젝트 수 쿼터
다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한
@ -188,7 +192,8 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 |
| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 |
| `NotBestEffort` | 서비스 품질이 나쁜 파드 |
| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `PriorityClass` | 지정된 [프라이어리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. |
| `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 |
`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다.
@ -429,6 +434,63 @@ memory 0 20Gi
pods 0 10
```
### 네임스페이스 간 파드 어피니티 쿼터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
`namespaces` 또는 `namespaceSelector` 필드를 설정할 수 있는 파드를 제어한다.
안티-어피니티 제약 조건이 있는 파드는 장애 도메인에서 다른 모든 네임스페이스의 파드가 예약되지 않도록
차단할 수 있으므로 사용자가 네임스페이스 간 어피니티 용어를
사용하지 못하도록 하는 것이 바람직할 수 있다.
이 범위 오퍼레이터를 사용하면 `CrossNamespaceAffinity` 범위와 하드(hard) 제한이 0인
네임스페이스에 리소스 쿼터 오브젝트를 생성하여 특정 네임스페이스(아래 예에서 `foo-ns`)가 네임스페이스 간 파드 어피니티를
사용하는 파드를 사용하지 못하도록 방지할 수 있다.
```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: disable-cross-namespace-affinity
namespace: foo-ns
spec:
hard:
pods: "0"
scopeSelector:
matchExpressions:
- scopeName: CrossNamespaceAffinity
```
오퍼레이터가 기본적으로 `namespaces` 및 `namespaceSelector` 사용을 허용하지 않고,
특정 네임스페이스에만 허용하려는 경우, kube-apiserver 플래그 --admission-control-config-file를
다음의 구성 파일의 경로로 설정하여 `CrossNamespaceAffinity` 를
제한된 리소스로 구성할 수 있다.
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: ResourceQuotaConfiguration
limitedResources:
- resource: pods
matchScopes:
- scopeName: CrossNamespaceAffinity
```
위의 구성을 사용하면, 파드는 생성된 네임스페이스에 `CrossNamespaceAffinity` 범위가 있는 리소스 쿼터 오브젝트가 있고,
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
## 요청과 제한의 비교 {#requests-vs-limits}
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.

33
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -11,18 +11,17 @@ weight: 20
<!-- overview -->
{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나,
특정 노드들을 선호하도록 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나,
자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만
간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다.
특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만
간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다.
예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서
많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다.
<!-- body -->
## 노드 셀렉터(nodeSelector)
@ -120,13 +119,13 @@ spec:
여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고,
후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고
@ -271,6 +270,18 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
연관된 `matchExpressions` 가 모두 충족되어야 한다.
#### 네임스페이스 셀렉터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
#### 더 실용적인 유스케이스
파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은

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

@ -86,6 +86,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기

13
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
View File

@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다.
본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝
최적화에 대해 설명한다.
<!-- body -->
큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간
@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
`percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml`
일 수 있다)을 편집한 다음 스케줄러를 재시작 한다.
값을 변경하려면,
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
이를 변경한 후에 다음을 실행해서
@ -99,7 +99,6 @@ algorithmSource:
percentageOfNodesToScore: 50
```
### percentageOfNodesToScore 튜닝
`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며
@ -159,3 +158,7 @@ percentageOfNodesToScore: 50
```
모든 노드를 검토한 후, 노드 1로 돌아간다.
## {{% heading "whatsnext" %}}
* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인

2
content/ko/docs/concepts/security/controlling-access.md
View File

@ -38,7 +38,7 @@ API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.

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

@ -383,7 +383,7 @@ $ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
<h1>Welcome to nginx!</h1>
```
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
```shell
kubectl edit svc my-nginx

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

@ -11,11 +11,11 @@ weight: 70
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
IPv4/IPv6 이중 스택을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}} 와 {{< glossary_tooltip text="서비스" term_id="service" >}} 에 IPv4와 IPv6 주소를 모두 할당 할 수 있다.
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
만약 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택 네트워킹을 활성화하면, 클러스터는 IPv4와 IPv6 주소의 동시 할당을 지원하게 된다.
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
@ -23,7 +23,7 @@ weight: 70
## 지원되는 기능
쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다.
쿠버네티스 클러스터의 IPv4/IPv6 이중 스택은 다음의 기능을 제공한다.
* 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
* IPv4와 IPv6 지원 서비스
@ -40,34 +40,34 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
## IPv4/IPv6 이중 스택 활성화
## IPv4/IPv6 이중 스택 구성
IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다.
IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.)
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
* kube-apiserver:
* `--feature-gates="IPv6DualStack=true"`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* kube-controller-manager:
* `--feature-gates="IPv6DualStack=true"`
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
* kubelet:
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
{{< note >}}
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)
1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다.
필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에
`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다.
{{< /note >}}
## 서비스
클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다.
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
@ -76,11 +76,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
* `PreferDualStack`:
* 클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다.
* 클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 `SingleStack`과 동일한 동작을 따른다.
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.)
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
* 클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
@ -121,7 +119,7 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,
#### 기존 서비스의 이중 스택 기본값
이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다.
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.)
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
@ -237,3 +235,5 @@ spec:
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화
](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)

63
content/ko/docs/concepts/services-networking/endpoint-slices.md
View File

@ -1,13 +1,13 @@
---
title: 엔드포인트슬라이스
content_type: concept
weight: 35
weight: 45
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
_엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
@ -50,7 +50,7 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로
리소스 샘플이 있다.
```yaml
apiVersion: discovery.k8s.io/v1beta1
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: example-abc
@ -67,13 +67,12 @@ endpoints:
conditions:
ready: true
hostname: pod-1
topology:
kubernetes.io/hostname: node-1
topology.kubernetes.io/zone: us-west2-a
nodeName: node-1
zone: us-west2-a
```
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를
갖도록 엔드포인트슬라이스를
생성하고 관리한다. `--max-endpoints-per-slice`
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
@ -98,9 +97,9 @@ endpoints:
#### 준비
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여
`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여
파드 종료 준비 상태(readiness)를 검사해야 한다.
이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
@ -110,16 +109,16 @@ endpoints:
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다.
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
이 조건을 확인해야 한다.
{{< note >}}
`serving`은 `ready`와 거의 동일하지만 `ready`의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며,
클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며,
클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다.
{{< /note >}}
@ -133,30 +132,26 @@ endpoints:
### 토폴로지 정보 {#토폴로지}
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다.
토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및
영역에 대한 정보가 포함된다. 엔드포인트슬라이스의 다음의 엔드 포인트별
필드에서 사용할 수 있다.
*`nodeName` - 이 엔드 포인트가 있는 노드의 이름이다.
*`zone` - 이 엔드 포인트가 있는 영역이다.
{{< note >}}
엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다.
토폴로지에서 `kubernetes.io/hostname`을 설정하는 대신 새로운 `nodeName` 필드가
사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는
엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는
엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다.
v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
`topology` 가 효과적으로 제거되었다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
{{< /note >}}
엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다.
* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름.
* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름.
* `topology.kubernetes.io/region` - 이 엔드포인트가 있는 지역의 이름.
이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서
파생된다. 호스트 이름 레이블은 해당 파드의
NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당
노드에서 이름이 같은 값을 나타낸다.
### 관리
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스

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

@ -218,7 +218,19 @@ Events: <none>
{{< codenew file="service/networking/external-lb.yaml" >}}
IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
추가 구성을 참조하는데 사용할 수 있다.
추가 구현 별 구성을 참조하는데 사용할 수 있다.
#### 네임스페이스 범위의 파라미터
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의
리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를
설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다.
{{< codenew file="service/networking/namespaced-params.yaml" >}}
### 사용중단(Deprecated) 어노테이션
@ -257,7 +269,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
{{< codenew file="service/networking/test-ingress.yaml" >}}
만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의
만약 `kubectl apply -f` 를 사용해서 생성한다면 추가한 인그레스의
상태를 볼 수 있어야 한다.
```bash

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

@ -220,18 +220,72 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
{{< /note >}}
## 포트 범위 지정
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
다음 예와 같이 `endPort` 필드를 사용하면, 이 작업을 수행할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: multi-port-egress
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 32000
endPort: 32768
```
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
* 두 포트 모두 숫자여야 한다.
{{< note >}}
클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
{{< /note >}}
## 이름으로 네임스페이스 지정
{{< feature-state state="beta" for_k8s_version="1.21" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우
모든 네임스페이스에 변경할 수 없는(immutable) 레이블 `kubernetes.io/metadata.name` 을 설정한다.
레이블의 값은 네임스페이스 이름이다.
네트워크폴리시는 일부 오브젝트 필드가 있는 이름으로 네임스페이스를 대상으로 지정할 수 없지만, 표준화된 레이블을 사용하여
특정 네임스페이스를 대상으로 지정할 수 있다.
## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.
쿠버네티스 {{< skew latestVersion >}}부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다.
- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
- 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
- 이름으로 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
- 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
- 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
- 고급 정책 쿼리 및 도달 가능성 도구.
- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능.
- 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
- 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
- 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).

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

@ -1,10 +1,8 @@
---
title: 서비스 토폴로지
feature:
title: 서비스 토폴로지
description: >
클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅.
title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅
content_type: concept
weight: 10
---
@ -12,7 +10,16 @@ weight: 10
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
{{< note >}}
이 기능, 특히 알파 `topologyKeys` API는 쿠버네티스 v1.21부터
더 이상 사용되지 않는다.
쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints/)는
유사한 기능을 제공한다.
{{</ note >}}
_서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
@ -20,33 +27,33 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노
우선적으로 라우팅되도록 지정할 수 있다.
<!-- body -->
## 소개
기본적으로 `ClusterIP` 또는 `NodePort` 서비스로 전송된 트래픽은 서비스의
모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)"
트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만,
`ClusterIP` 서비스에서는 지원되지 않으며 더 복잡한
토폴로지 &mdash; 영역별 라우팅과 같은 &mdash; 에서는 불가능 했다.
_서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서
노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록
함으로써 이 문제를 해결한다.
모든 백엔드 주소로 라우팅될 수 있다. 쿠버네티스 1.7을 사용하면 트래픽을 수신한
동일한 노드에서 실행 중인 파드로 "외부(external)" 트래픽을 라우팅할 수
있다. `ClusterIP` 서비스의 경우, 라우팅에 대한 동일한 노드 기본 설정이
불가능했다. 또한 동일한 영역 내의 엔드 포인트에 대한 라우팅을 선호하도록
클러스터를 구성할 수도 없다.
서비스에 `topologyKeys` 를 설정하면, 출발 및 대상 노드에 대한
노드 레이블을 기반으로 트래픽을 라우팅하는 정책을 정의할 수 있다.
소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에
적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)"
노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을
동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는
지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다.
다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
연결된 노드로 트래픽을 유지하는 것이 있다.
소스와 목적지 사이의 레이블 일치를 통해 클러스터 운영자는
서로 "근접(closer)"하거나 "먼(father)" 노드 그룹을 지정할 수 있다.
자신의 요구 사항에 맞는 메트릭을 나타내는 레이블을 정의할 수 있다.
예를 들어, 퍼블릭 클라우드에서는 지역 간의 트래픽에는 관련 비용이 발생(지역 내
트래픽은 일반적으로 그렇지 않다)하기 때문에, 네트워크 트래픽을 동일한 지역 내에 유지하는 것을
선호할 수 있다. 다른 일반적인 필요성으로는 데몬셋(DaemonSet)이 관리하는
로컬 파드로 트래픽을 라우팅하거나, 대기 시간을 최소화하기 위해
동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을
유지하는 것이 있다.
## 서비스 토폴로지 사용하기
만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서
만약 클러스터에서 `ServiceTopology` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우, 서비스 사양에서
`topologyKeys` 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
@ -196,5 +203,3 @@ spec:
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기.
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기.

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

@ -187,9 +187,14 @@ ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
### 엔드포인트슬라이스
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
@ -513,8 +518,12 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다.
포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다.
이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
`--nodeport-addresses` 플래그 또는
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@ -530,7 +539,9 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설
하나 이상의 노드 IP를 직접 노출시킬 수 있다.
이 서비스는 `<NodeIP>:spec.ports[*].nodePort`와
`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, <NodeIP>는 NodeIP를 필터링한다.)
`.spec.clusterIP:spec.ports[*].port`로 표기된다.
kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의
동등한 필드가 설정된 경우, `<NodeIP>` 는 노드 IP를 필터링한다.
예를 들면
@ -628,6 +639,25 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
로드 밸런서 구현)은 이 필드가 설정된 서비스를 무시한다.
`spec.loadBalancerClass` 는 `LoadBalancer` 유형의 서비스에서만 설정할 수 있다.
한 번 설정하면 변경할 수 없다.
`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
#### 내부 로드 밸런서
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
@ -785,8 +815,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
```
위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우,
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히
프록시만 하는 HTTP이다.
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다.
쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
@ -958,7 +987,8 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
| 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
|------|----------|---------|------------|---------------------|
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
| 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
| MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

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

@ -29,7 +29,7 @@ _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리
_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고).
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다.
[실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다.

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

@ -34,7 +34,7 @@ weight: 10
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
매체와 내용은 사용된 특정 볼륨의 유형에 따라
결정된다.
@ -149,14 +149,16 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
#### azureFile CSI 마이그레이션
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI
드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver)
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
알파 기능을 활성화해야 한다.
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
### cephfs
@ -205,14 +207,17 @@ spec:
#### 오픈스택 CSI 마이그레이션
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI
드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를
설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
베타 기능을 활성화해야 한다.
Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다.
기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다.
[오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가
클러스터에 설치되어 있어야 한다.
`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다.
`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이
Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다.
### 컨피그맵(configMap) {#configmap}

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

@ -10,7 +10,7 @@ weight: 80
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
_크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다.
@ -115,12 +115,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
잡은 그 잡이 대표하는 파드 관리에 책임이 있다.
## 새 컨트롤러
## 컨트롤러 버전 {#new-controller}
쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다.
쿠버네티스 v1.21부터 크론잡 컨트롤러의 두 번째 버전이
기본 구현이다. 기본 크론잡 컨트롤러를 비활성화하고
대신 원래 크론잡 컨트롤러를 사용하려면, `CronJobControllerV2`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달하고,
이 플래그를 `false` 로 설정한다. 예를 들면, 다음과 같다.
```
--feature-gates="CronJobControllerV2=true"
--feature-gates="CronJobControllerV2=false"
```

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

@ -706,7 +706,7 @@ nginx-deployment-618515232 11 11 11 7m
하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
* 예를 들어, 방금 생성된 디플로이먼트의 경우
* 예를 들어, 생성된 디플로이먼트의 경우
디플로이먼트 상세 정보를 가져온다.
```shell
kubectl get deploy

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

@ -16,7 +16,8 @@ weight: 50
잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의
성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한
파드가 정리된다.
파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가
삭제된다.
간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다.
첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는
@ -98,8 +99,8 @@ echo $pods
pi-5rwd7
```
여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output=jsonpath` 옵션은 반환된 목록의
각각의 파드에서 이름을 가져와서 표현하는 방식을 지정한다.
여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output = jsonpath` 옵션은 반환된
목록에 있는 각 파드의 이름으로 표현식을 지정한다.
파드 중 하나를 표준 출력으로 본다.
@ -145,8 +146,8 @@ kubectl logs $pods
- 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다.
1. *고정적(fixed)인 완료 횟수* 를 가진 병렬 잡:
- `.spec.completions` 에 0이 아닌 양수 값을 지정한다.
- 잡은 전체 작업을 나타내며 1에서 `.spec.completions` 까지의 범위의 각 값에 대해 한 개씩 성공한 파드가 있으면 완료된다.
- **아직 구현되지 않음:** 각 파드에게는 1부터 `.spec.completions` 까지의 범위 내의 서로 다른 인덱스가 전달된다.
- 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다.
- `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다.
1. *작업 큐(queue)* 가 있는 병렬 잡:
- `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다.
- 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다.
@ -166,7 +167,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
다른 유형의 잡을 사용하는 방법에 대한 더 자세한 정보는 [잡 패턴](#잡-패턴) 섹션을 본다.
#### 병렬 처리 제어하기
요청된 병렬 처리(`.spec.parallelism`)는 음수가 아닌 값으로 설정할 수 있다.
@ -185,6 +185,33 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
- 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다.
- 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다.
### 완료 모드
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< note >}}
인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
{{< /note >}}
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
- `NonIndexed` (기본값): `.spec.completions` 가 성공적으로
완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
잡은 암시적으로 `NonIndexed` 이다.
- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수
있지만, 그 중 하나만 완료 횟수에 포함된다.
## 파드와 컨테이너 장애 처리하기
파드내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을
@ -348,12 +375,12 @@ spec:
여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정하지 않은 앱을 사용하는가? | Kube 1.1에서 작동하는가? |
| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 때때로 | ✓ |
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
| 정적 작업이 할당된 단일 잡 | ✓ | | ✓ | |
| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? |
| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 |
| [가변 파드 수를 가진 큐] | ✓ | ✓ | |
| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ |
| [잡 템플릿 확장] | | | ✓ |
`.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는
동일한 [`사양`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)을 갖는다. 이 의미는
@ -364,16 +391,121 @@ spec:
이 표는 각 패턴에 필요한 `.spec.parallelism` 그리고 `.spec.completions` 설정을 보여준다.
여기서 `W` 는 작업 항목의 수이다.
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | 1 | 1이어야 함 |
| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | any |
| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any |
| 정적 작업이 할당된 단일 잡 | W | any |
| 패턴 | `.spec.completions` | `.spec.parallelism` |
| ----------------------------------------- |:-------------------:|:--------------------:|
| [작업 항목 당 파드가 있는 큐] | W | any |
| [가변 파드 수를 가진 큐] | null | any |
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
| [잡 템플릿 확장] | 1 | 1이어야 함 |
[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/
[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/
[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/
## 고급 사용법
### 잡 일시 중지
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
{{< note >}}
잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다.
{{< /note >}}
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
즉시 파드 생성을 시작하고 잡이 완료될 때까지
계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에
다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다.
`.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로
생성된다.
잡이 일시 중지에서 재개되면, 해당 `.status.startTime` 필드가
현재 시간으로 재설정된다. 즉, 잡이 일시 중지 및 재개되면 `.spec.activeDeadlineSeconds`
타이머가 중지되고 재설정된다.
잡을 일시 중지하면 모든 활성 파드가 삭제된다. 잡이
일시 중지되면, SIGTERM 시그널로 [파드가 종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
파드의 정상 종료 기간이 적용되며 사용자의 파드는 이 기간 동안에
이 시그널을 처리해야 한다. 나중에 진행 상황을 저장하거나
변경 사항을 취소하는 작업이 포함될 수 있다. 이 방법으로 종료된 파드는
잡의 `completions` 수에 포함되지 않는다.
일시 중지된 상태의 잡 정의 예시는 다음과 같다.
```shell
kubectl get job myjob -o yaml
```
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
suspend: true
parallelism: 1
completions: 5
template:
spec:
...
```
잡의 상태를 사용하여 잡이 일시 중지되었는지 또는 과거에 일시 중지되었는지
확인할 수 있다.
```shell
kubectl get jobs/myjob -o yaml
```
```json
apiVersion: batch/v1
kind: Job
# .metadata and .spec omitted
status:
conditions:
- lastProbeTime: "2021-02-05T13:14:33Z"
lastTransitionTime: "2021-02-05T13:14:33Z"
status: "True"
type: Suspended
startTime: "2021-02-05T13:13:48Z"
```
"True" 상태인 "Suspended" 유형의 잡의 컨디션은 잡이
일시 중지되었음을 의미한다. 이 `lastTransitionTime` 필드는 잡이 일시 중지된
기간을 결정하는 데 사용할 수 있다. 해당 컨디션의 상태가 "False"이면, 잡이
이전에 일시 중지되었다가 현재 실행 중이다. 이러한 컨디션이
잡의 상태에 없으면, 잡이 중지되지 않은 것이다.
잡이 일시 중지 및 재개될 때에도 이벤트가 생성된다.
```shell
kubectl describe jobs/myjob
```
```
Name: myjob
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl
Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl
Normal Suspended 11m job-controller Job suspended
Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44
Normal Resumed 3s job-controller Job resumed
```
마지막 4개의 이벤트, 특히 "Suspended" 및 "Resumed" 이벤트는
`.spec.suspend` 필드를 전환한 결과이다. 이 두 이벤트 사이의 시간동안
파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시
시작되었음을 알 수 있다.
### 자신의 파드 셀렉터를 지정하기
일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다.

12
content/ko/examples/service/networking/namespaced-params.yaml Normal file
View File

@ -0,0 +1,12 @@
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com
kind: IngressParameters
name: external-lb
namespace: external-configuration
scope: Namespace