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

Merge pull request #36810 from kubernetes/dev-1.24-ko.3 

Update release-1.24 with the latest Korean localization work about 1.24
pull/37149/head
Kubernetes Prow Robot 2022-09-14 10:13:01 -07:00 committed by GitHub
parent 7a39b4fc2b a1785fb338
commit 3a4654353a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
234 changed files with 5370 additions and 1666 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/ko/_index.html
View File

@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
<button id="desktopShowVideoButton" onclick="kub.showVideo()">비디오 보기</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu23" button id="desktopKCButton">KubeCon Europe (2023년 4월 17~21일) 참가하기</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe" button id="desktopKCButton">KubeCon Europe (2023년 4월 17~21일) 참가하기</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

4
content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
View File

@ -21,7 +21,7 @@ evergreen: true
**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.**
요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated).
도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서
계속 작동될 것입니다.
@ -72,7 +72,7 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이
쿠버네티스에 왜 필요할까요?
도커는 [컨테이너 런타임 인터페이스](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
도커는 [컨테이너 런타임 인터페이스](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나
이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지
컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.

20
content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md
View File

@ -18,18 +18,18 @@ evergreen: true
연간 4회에서 3회로의 릴리스 케이던스 변경을 통해 프로젝트의 다양한 측면(기여와 릴리스가 관리되는 방법, 업그레이드 및 최신 릴리스 유지에 대한 커뮤니티의 역량 등)에 대한 균형을 이루고자 하였습니다.
더 자세한 사항은 공식 블로그 포스트 [쿠버네티스 릴리스 케이던스 변경: 알아두어야 할 사항](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/)에서 확인할 수 있습니다.
더 자세한 사항은 공식 블로그 포스트 [쿠버네티스 릴리스 케이던스 변경: 알아두어야 할 사항](/blog/2021/07/20/new-kubernetes-release-cadence/)에서 확인할 수 있습니다.
## 주요 주제
### 서버-사이드 어플라이(Server-side Apply)가 GA로 졸업
[서버-사이드 어플라이](https://kubernetes.io/docs/reference/using-api/server-side-apply/)는 쿠버네티스 API 서버에서 동작하는 신규 필드 오너십이며 오브젝트 병합 알고리즘입니다. 서버-사이드 어플라이는 사용자와 컨트롤러가 선언적인 구성을 통해서 자신의 리소스를 관리할 수 있도록 돕습니다. 이 기능은 단순히 fully specified intent를 전송하는 것만으로 자신의 오브젝트를 선언적으로 생성 또는 수정할 수 있도록 허용합니다. 몇 릴리스에 걸친 베타 과정 이후, 서버-사이드 어플라이는 이제 GA(generally available)가 되었습니다.
[서버-사이드 어플라이](/docs/reference/using-api/server-side-apply/)는 쿠버네티스 API 서버에서 동작하는 신규 필드 오너십이며 오브젝트 병합 알고리즘입니다. 서버-사이드 어플라이는 사용자와 컨트롤러가 선언적인 구성을 통해서 자신의 리소스를 관리할 수 있도록 돕습니다. 이 기능은 단순히 fully specified intent를 전송하는 것만으로 자신의 오브젝트를 선언적으로 생성 또는 수정할 수 있도록 허용합니다. 몇 릴리스에 걸친 베타 과정 이후, 서버-사이드 어플라이는 이제 GA(generally available)가 되었습니다.
### 외부 크리덴셜 제공자가 이제 스테이블이 됨
쿠버네티스 클라이언트 [크리덴셜 플러그인](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)에 대한 지원은 1.11부터 베타였으나, 쿠버네티스 1.22 릴리스에서 스테이블로 졸업하였습니다. 해당 GA 기능 집합은 인터랙티브 로그인 플로우(interactive login flow)를 제공하는 플러그인에 대한 향상된 지원을 포함합니다. 또한, 많은 버그가 수정되었습니다. 플러그인 개발은 [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)을 통해 시작할 수 있습니다.
쿠버네티스 클라이언트 [크리덴셜 플러그인](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)에 대한 지원은 1.11부터 베타였으나, 쿠버네티스 1.22 릴리스에서 스테이블로 졸업하였습니다. 해당 GA 기능 집합은 인터랙티브 로그인 플로우(interactive login flow)를 제공하는 플러그인에 대한 향상된 지원을 포함합니다. 또한, 많은 버그가 수정되었습니다. 플러그인 개발은 [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)을 통해 시작할 수 있습니다.
### etcd 3.5.0으로 변경
@ -65,13 +65,13 @@ SIG Windows는 계속해서 성장하는 개발자 커뮤니티를 지원하기
GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에서 제거되었습니다. 기존의 모든 오브젝트는 스테이블 APIs를 통해 상호 작용할 수 있습니다. 이 제거에는 `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, `CertificateSigningRequest` API의 베타 버전이 포함되었습니다.
전체 항목은 [사용 중단된 API에 대한 마이그레이션 지침](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22)과 블로그 포스트 [1.22에서 쿠버네티스 API와 제거된 기능: 알아두어야 할 사항](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)에서 확인 가능합니다.
전체 항목은 [사용 중단된 API에 대한 마이그레이션 지침](/docs/reference/using-api/deprecation-guide/#v1-22)과 블로그 포스트 [1.22에서 쿠버네티스 API와 제거된 기능: 알아두어야 할 사항](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)에서 확인 가능합니다.
### 임시(ephemeral) 컨테이너에 대한 API 변경 및 개선
1.22에서 [임시 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 생성하기 위한 API가 변경되었습니다. 임시 컨테이너 기능은 알파이며 기본적으로 비활성화되었습니다. 신규 API는 예전 API를 사용하려는 클라이언트에 대해 동작하지 않습니다.
1.22에서 [임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 생성하기 위한 API가 변경되었습니다. 임시 컨테이너 기능은 알파이며 기본적으로 비활성화되었습니다. 신규 API는 예전 API를 사용하려는 클라이언트에 대해 동작하지 않습니다.
스테이블 기능에 대해서, kubectl 도구는 쿠버네티스의 [버전 차이(skew) 정책](https://kubernetes.io/ko/releases/version-skew-policy/)을 따릅니다. 그러나, kubectl v1.21 이하의 버전은 임시 컨테이너에 대한 신규 API를 지원하지 않습니다. 만약 `kubectl debug`를 사용하여 임시 컨테이너를 생성할 계획이 있고 클러스터에서 쿠버네티스 v1.22로 구동하고 있는 경우, kubectl v1.21 이하의 버전에서는 그렇게 할 수 없다는 것을 알아두어야 합니다. 따라서 만약 클러스터 버전을 혼합하여 `kubectl debug`를 사용하려면 kubectl를 1.22로 업데이트하길 바랍니다.
스테이블 기능에 대해서, kubectl 도구는 쿠버네티스의 [버전 차이(skew) 정책](/ko/releases/version-skew-policy/)을 따릅니다. 그러나, kubectl v1.21 이하의 버전은 임시 컨테이너에 대한 신규 API를 지원하지 않습니다. 만약 `kubectl debug`를 사용하여 임시 컨테이너를 생성할 계획이 있고 클러스터에서 쿠버네티스 v1.22로 구동하고 있는 경우, kubectl v1.21 이하의 버전에서는 그렇게 할 수 없다는 것을 알아두어야 합니다. 따라서 만약 클러스터 버전을 혼합하여 `kubectl debug`를 사용하려면 kubectl를 1.22로 업데이트하길 바랍니다.
## 기타 업데이트
@ -99,9 +99,9 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에
# 릴리스 위치
쿠버네티스 1.22는 [여기](https://kubernetes.io/releases/download/)에서 다운로드할 수 있고, [GitHub 프로젝트](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0)에서도 찾을 수 있습니다.
쿠버네티스 1.22는 [여기](/releases/download/)에서 다운로드할 수 있고, [GitHub 프로젝트](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0)에서도 찾을 수 있습니다.
쿠버네티스를 시작하는 데 도움이 되는 좋은 자료가 많이 있습니다. 쿠버네티스 사이트에서 [상호 작용형 튜토리얼](https://kubernetes.io/ko/docs/tutorials/)을 수행할 수도 있고, [kind](https://kind.sigs.k8s.io)와 도커 컨테이너를 사용하여 로컬 클러스터를 사용자의 머신에서 구동해볼 수도 있습니다. 클러스터를 스크래치(scratch)부터 구축해보고 싶다면, Kelsey Hightower의 [쿠버네티스 어렵게 익히기(the Hard Way)](https://github.com/kelseyhightower/kubernetes-the-hard-way) 튜토리얼을 확인해보시기 바랍니다.
쿠버네티스를 시작하는 데 도움이 되는 좋은 자료가 많이 있습니다. 쿠버네티스 사이트에서 [상호 작용형 튜토리얼](/ko/docs/tutorials/)을 수행할 수도 있고, [kind](https://kind.sigs.k8s.io)와 도커 컨테이너를 사용하여 로컬 클러스터를 사용자의 머신에서 구동해볼 수도 있습니다. 클러스터를 스크래치(scratch)부터 구축해보고 싶다면, Kelsey Hightower의 [쿠버네티스 어렵게 익히기(the Hard Way)](https://github.com/kelseyhightower/kubernetes-the-hard-way) 튜토리얼을 확인해보시기 바랍니다.
# 릴리스 팀
@ -152,7 +152,7 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에
* [쿠버네티스 기여자](https://www.kubernetes.dev/) 웹사이트에서 기여에 대한 더 자세한 사항을 확인
* 최신 정보 업데이트를 위해 [@Kubernetesio](https://twitter.com/kubernetesio) 트위터 팔로우
* [논의(discuss)](https://discuss.kubernetes.io/)에서 커뮤니티 논의에 참여
* [슬랙](http://slack.k8s.io/)에서 커뮤니티에 참여
* [슬랙](https://slack.k8s.io/)에서 커뮤니티에 참여
* 쿠버네티스 [사용기](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) 공유
* 쿠버네티스에서 일어나는 일에 대한 자세한 사항을 [블로그](https://kubernetes.io/blog/)를 통해 읽기
* 쿠버네티스에서 일어나는 일에 대한 자세한 사항을 [블로그](/blog/)를 통해 읽기
* [쿠버네티스 릴리스 팀](https://github.com/kubernetes/sig-release/tree/master/release-team)에 대해 더 알아보기

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

@ -1,4 +1,7 @@
---
# reviewers:
# - dchen1107
# - liggitt
title: 컨트롤 플레인-노드 간 통신
content_type: concept
weight: 20
@ -8,29 +11,49 @@ aliases:
<!-- overview -->
이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다.
이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서
클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
<!-- body -->
## 노드에서 컨트롤 플레인으로의 통신
쿠버네티스에는 "허브 앤 스포크(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/) 형식을 사용해야 한다.
쿠버네티스에는 "허브 앤 스포크(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/)을 참고한다.
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록
클러스터에 대한 공개 루트 인증서(root certificate)로 프로비전해야 한다. 클라이언트 인증서(client certificate) 형식으로
kubelet의 클라이언트 자격 증명을 사용하는 것은 좋은 방법이다.
kubelet 클라이언트 인증서(client certificate)의 자동 프로비저닝은
[kubelet TLS 부트스트랩](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 참고한다.
API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
API 서버에 연결하려는 파드는 서비스 어카운트를 활용하여 안전하게
쿠버네티스가 공개 루트 인증서(root certificate)와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때
파드에 자동으로 주입할 수 있다.
`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는
가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.
결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한
기본 작동 모드는 기본적으로 보호되며
신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
## 컨트롤 플레인에서 노드로의 통신
컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다.
첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다.
두 번째는 API 서버의 _프록시_ 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에
이르는 것이다.
### API 서버에서 kubelet으로의 통신
@ -40,33 +63,56 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
* 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다.
* kubelet의 포트-포워딩 기능을 제공한다.
이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
위와 같은 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의
제공(serving) 인증서를 확인하지 않는다. 이는 연결이 중간자 공격(man-in-the-middle)에 시달리게 하며,
신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여
API 서버에 kubelet의 제공(serving) 인증서를 확인하는데 사용할 루트 인증서 번들을 제공한다.
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해
필요한 경우, API 서버와 kubelet 간 [SSH 터널링](#ssh-터널)을
사용한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다.
마지막으로, kubelet API를 보호하려면
[Kubelet 인증 및/또는 인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)를 활성화해야 한다.
### API 서버에서 노드, 파드 및 서비스로의 통신
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로
인증되거나 암호화되지 않는다. 이 연결에서 URL을 노드, 파드 또는 서비스 이름에 접두어 `https:` 을 붙여
보안 HTTPS 연결이 되도록 실행할 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않으며
클라이언트 자격 증명도 제공하지 않는다.
그래서 연결이 암호화되는 동안 그 어떤 무결성도 보장되지 않는다.
이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** .
### SSH 터널
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다.
이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고
(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해
kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 노드가 실행 중인 네트워크의 외부로 트래픽이
노출되지 않도록 한다.
{{< note >}}
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 대체한다.
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다.
[Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을
대체한다.
{{< note >}}
### Konnectivity 서비스 {#konnectivity-service}
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
SSH 터널을 대체로, Konnectivity 서비스는 컨트롤 플레인과 클러스터 간 통신에 TCP 레벨 프록시를 제공한다.
Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와
노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다.
Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고
네트워크 연결을 유지한다.
Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은
이 연결을 통과한다.
[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라
클러스터에서 Konnectivity 서비스를 설정한다.

59
content/ko/docs/concepts/architecture/garbage-collection.md
View File

@ -16,7 +16,8 @@ weight: 50
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
* {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다:
* 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는
온프레미스
* [노드 리스(Lease) 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)
## 소유자(Owners)와 종속(dependents) {#owners-dependents}
@ -65,7 +66,8 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
* 포그라운드 캐스케이딩 삭제(Foreground cascading deletion)
* 백그라운드 캐스케이딩 삭제(Background cascading deletion)
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여
가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
### 포그라운드 캐스케이딩 삭제 {#foreground-deletion}
@ -77,90 +79,99 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
오브젝트가 삭제 표시된 시간으로 설정한다.
* 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로
설정한다.
* 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다.
* 오브젝트는 삭제 과정이 완료되기 전까지
쿠버네티스 API를 통해 조회할 수 있다.
소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다.
모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다.
이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다.
이 시점에서 오브젝트는 더 이상
쿠버네티스 API를 통해 조회할 수 없다.
포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다.
더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
더 자세한 내용은 [Use foreground cascading deletion](/ko/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)를
더 자세한 내용은 [Use background cascading deletion](/ko/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)를 참고한다.
기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다. 이 행동을 오버라이드하는 방법을 보려면,
[Delete owner objects and orphan dependents](/ko/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다.
## 사용되지 않는 컨테이너와 이미지 가비지 수집 {#containers-images}
{{<glossary_tooltip text="kubelet" term_id="kubelet">}}은
사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다
수행한다. 외부 가비지 수집 도구는 Kubelet 의 행동을 중단시키고
수행한다. 외부 가비지 수집 도구는 kubelet 의 행동을 중단시키고
존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다.
사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면,
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 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의 일부인 *이미지 관리자*가
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
모든 이미지의 라이프사이클을 관리한다.
Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다.
kubelet은 가비지 수집 결정을 내릴 때,
다음 디스크 사용량 제한을 고려한다.
* `HighThresholdPercent`
* `LowThresholdPercent`
`HighThresholdPercent` 값을 초과한 디스크 사용량은
마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는
가비지 수집을 트리거한다. Kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
가비지 수집을 트리거한다. kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
이미지를 삭제한다.
### 컨테이너 이미지 가비지 수집 {#container-image-garbage-collection}
Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다:
kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로
사용되지 않는 컨테이너들을 삭제한다:
* `MinAge`: Kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다.
* `MinAge`: kubelet이 가비지 수집할 수 있는 최소 나이.
`0`으로 세팅하여 비활성화할 수 있다.
* `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수.
`0`으로 세팅하여 비활성화할 수 있다.
* `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수
`0`으로 세팅하여 비활성화할 수 있다.
위 변수와 더불어, Kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다.
위 변수와 더불어, kubelet은 식별할 수 없고 삭제된 컨테이너들을
오래된 순서대로 가비지 수집한다.
`MaxPerPodContainer`와 `MaxContainer`는
파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이
전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때,
서로 충돌이 발생할 수 있다.
이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
이 상황에서 kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고
가장 오래된 컨테이너들을 축출한다.
또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다.
{{<note>}}
Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
{{</note>}}
## 가비지 수집 구성하기 {#configuring-gc}
자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다.
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다:
자원을 관리하는 컨트롤러의 옵션을 구성하여
가비지 컬렉션을 수정할 수 있다.
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다.
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/docs/tasks/administer-cluster/use-cascading-deletion/)
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/ko/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/) -->
@ -168,5 +179,5 @@ Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을
## {{% heading "whatsnext" %}}
* [쿠버네티스 오브젝트의 소유권](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자.
* 쿠버네티스 [finalizers](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
* 쿠버네티스 [finalizers](/ko/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
* 완료된 잡을 정리하는 [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자.

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

@ -1,7 +1,7 @@
---
# reviewers:
# - caesarxuchao
# - dchen1107
title: 노드
content_type: concept
weight: 10
@ -476,13 +476,11 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
기존의 셧다운된 노드가 정상으로 돌아오지 못하면,
이러한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 영원히 고착될 것이다.
위와 같은 상황을 완화하기 위해,
사용자가 `node.kubernetes.io/out-of-service` 테인트를
위와 같은 상황을 완화하기 위해, 사용자가 `node.kubernetes.io/out-of-service` 테인트를
`NoExecute` 또는 `NoSchedule` 값으로 추가하여
노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다.
`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고,
노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우,
`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
가 활성화되어 있고, 노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우,
노드에 매치되는 톨러레이션이 없다면 노드 상의 파드는 강제로 삭제될 것이고,
노드 상에서 종료되는 파드에 대한 볼륨 해제(detach) 작업은 즉시 수행될 것이다.
이를 통해 서비스 불가 상태 노드의 파드가 빠르게 다른 노드에서 복구될 수 있다.
@ -492,7 +490,6 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
1. 매치되는 `out-of-service` 톨러레이션이 없는 파드를 강제로 삭제한다.
2. 이러한 파드에 대한 볼륨 해제 작업을 즉시 수행한다.
{{< note >}}
- `node.kubernetes.io/out-of-service` 테인트를 추가하기 전에,
노드가 완전한 셧다운 또는 전원 꺼짐 상태에 있는지
@ -500,8 +497,6 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
- 사용자가 서비스 불가 상태 테인트를 직접 추가한 것이기 때문에,
파드가 다른 노드로 옮겨졌고 셧다운 상태였던 노드가 복구된 것을 확인했다면
사용자가 서비스 불가 상태 테인트를 수동으로 제거해야 한다.
{{< /note >}}
### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown}

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

@ -1,8 +1,8 @@
---
title: 클러스터 관리
# reviewers:
# - davidopp
# - lavalamp
weight: 100
content_type: concept
description: >
@ -11,31 +11,37 @@ no_list: true
---
<!-- overview -->
클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
<!-- body -->
## 클러스터 계획
쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다.
쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다.
이 문서에 나열된 솔루션을 *배포판* 이라고 한다.
{{< note >}}
모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다.
{{< /note >}}
{{< note >}}
모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된
배포판을 선택한다.
{{< /note >}}
가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다.
- 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가?
- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약
후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
더 다양한 선택을 제공한다.
- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
- 컴퓨터에서 쿠버네티스를 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가?
사용자의 필요에 따라 가장 적합한 배포판을 선택한다.
- [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가?
아니면, **자체 클러스터를 호스팅** 할 것인가?
- 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나?
쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다.
- **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우,
어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다.
- 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가?
- **클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가?
만약 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만,
더 다양한 선택을 제공한다.
- 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자.
## 클러스터 관리
@ -45,29 +51,43 @@ no_list: true
## 클러스터 보안
* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여
인증서를 생성하는 단계를 설명한다.
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은
쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다.
* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는
쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다.
* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
* [인증](/docs/reference/access-authn-authz/authentication/)은
다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다.
* [인가](/ko/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
* [인가](/ko/docs/reference/access-authn-authz/authorization/)는
인증과는 별개로, HTTP 호출 처리 방법을 제어한다.
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는
인증과 권한 부여 후
쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는
관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다
.
* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는
쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
### kubelet 보안
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
* [Kubelet 인증/인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)
## 선택적 클러스터 서비스
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은
DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다.
* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은
쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.
* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다.

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

@ -1,7 +1,7 @@
---
# reviewers:
# - piosz
# - x13n
title: 로깅 아키텍처
content_type: concept
weight: 60

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

@ -1,6 +1,6 @@
---
# reviewers:
# - janetkuo
title: 리소스 관리
content_type: concept
weight: 40

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

@ -1,6 +1,6 @@
---
# reviewers:
# - thockin
title: 클러스터 네트워킹
content_type: concept
weight: 50

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

@ -1,7 +1,7 @@
---
# reviewers:
# - dims
# - 44past4
title: 시스템 로그
content_type: concept
weight: 60

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

@ -1,5 +1,9 @@
---
title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
# reviewers:
# - brancz
# - logicalhan
# - RainbowMango
content_type: concept
weight: 60
---

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

@ -1,8 +1,8 @@
---
title: 쿠버네티스 시스템 컴포넌트에 대한 추적(trace)
# reviewers:
# - logicalhan
# - lilic
content_type: concept
weight: 60
---

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

@ -331,7 +331,7 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으
* `spec.containers[].resources.requests.ephemeral-storage`
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
E, P, T, G, M, k와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
예를 들어, 다음은 거의 동일한 값을 나타낸다.
@ -340,6 +340,10 @@ Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
- `129M`
- `123Mi`
접미사의 대소문자에 유의한다.
`400m`의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다.
이 사람은 아마도 400 메비바이트(mebibytes) (`400Mi`) 또는 400 메가바이트 (`400M`) 를 요청하고 싶었을 것이다.
다음 예에서, 파드에 두 개의 컨테이너가 있다.
각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다.
각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다.
@ -639,7 +643,7 @@ spec:
프로세스 ID(PID) 제한은 kubelet의 구성에 대해
주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다.
자세한 내용은 [PID 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
자세한 내용은 [PID 제한](/ko/docs/concepts/policy/pid-limiting/)을 참고한다.
## 문제 해결

6
content/ko/docs/concepts/configuration/overview.md
View File

@ -1,6 +1,6 @@
---
# reviewers:
# - mikedanese
title: 구성 모범 사례
content_type: concept
weight: 10
@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
## 레이블 사용하기
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.

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

@ -1,6 +1,6 @@
---
# reviewers:
# - mikedanese
title: 시크릿(Secret)
content_type: concept
feature:

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

@ -2,6 +2,9 @@
title: 컨테이너
weight: 40
description: 런타임 의존성과 함께 애플리케이션을 패키징하는 기술
# reviewers:
# - erictune
# - thockin
content_type: concept
no_list: true
---

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

@ -1,7 +1,7 @@
---
# reviewers:
# - mikedanese
# - thockin
title: 컨테이너 환경 변수
content_type: concept
weight: 20

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

@ -1,7 +1,7 @@
---
# reviewers:
# - mikedanese
# - thockin
title: 컨테이너 라이프사이클 훅(Hook)
content_type: concept
weight: 30

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

@ -1,7 +1,7 @@
---
# reviewers:
# - erictune
# - thockin
title: 이미지
content_type: concept
weight: 10

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

@ -1,7 +1,7 @@
---
# reviewers
# - tallclair
# - dchen1107
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
@ -81,7 +81,7 @@ handler: myconfiguration
## 사용
클러스터에 런타임클래스를 설정하고 나면,
클러스터에 런타임클래스를 설정하고 나면,
다음과 같이 파드 스펙에 `runtimeClassName`를 명시하여 해당 런타임클래스를 사용할 수 있다.
```yaml
@ -116,7 +116,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
살펴본다.
#### {{< glossary_tooltip term_id="cri-o" >}}
@ -136,7 +136,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
`scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.

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

@ -2,11 +2,11 @@
title: 쿠버네티스 확장
weight: 110
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
# reviewers:
# - erictune
# - lavalamp
# - cheftako
# - chenopis
feature:
title: 확장성을 고려하여 설계됨
description: >
@ -244,7 +244,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
기본 스케줄러를 완전히 교체하거나,
[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
[여러 스케줄러](/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
동시에 실행할 수 있다.
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할

8
content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -1,9 +1,9 @@
---
title: 쿠버네티스 API 애그리게이션 레이어(aggregation layer)
# reviewers:
# - lavalamp
# - cheftako
# - chenopis
content_type: concept
weight: 10
---

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

@ -1,8 +1,8 @@
---
title: 커스텀 리소스
# reviewers:
# - enisoc
# - deads2k
content_type: concept
weight: 10
---

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

@ -1,8 +1,8 @@
---
# reviewers:
# - dcbw
# - freehan
# - thockin
title: 네트워크 플러그인
content_type: concept
weight: 10
@ -67,7 +67,7 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
```json
{
"name": "k8s-pod-network",
"cniVersion": "0.3.0",
"cniVersion": "0.4.0",
"plugins": [
{
"type": "calico",
@ -106,7 +106,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
```json
{
"name": "k8s-pod-network",
"cniVersion": "0.3.0",
"cniVersion": "0.4.0",
"plugins": [
{
"type": "calico",

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

@ -1,6 +1,6 @@
---
# reviewers:
# - lavalamp
title: 쿠버네티스 컴포넌트
content_type: concept
description: >

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

@ -1,6 +1,6 @@
---
# reviewers:
# - chenopis
title: 쿠버네티스 API
content_type: concept
weight: 30

6
content/ko/docs/concepts/overview/what-is-kubernetes.md
View File

@ -1,7 +1,7 @@
---
# reviewers:
# - bgrant0607
# - mikedanese
title: 쿠버네티스란 무엇인가?
description: >
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다.

86
content/ko/docs/concepts/overview/working-with-objects/finalizers.md Normal file
View File

@ -0,0 +1,86 @@
---
title: 파이널라이저
content_type: concept
weight: 60
---
<!-- overview -->
{{<glossary_definition term_id="finalizer" length="long">}}
파이널라이저(Finalizer)를 사용하면 리소스를 삭제하기 전 특정 정리 작업을 수행하도록
{{<glossary_tooltip term_id="controller">}}에 경고하여
리소스의 {{<glossary_tooltip term_id="garbage-collection">}}을 제어할 수 있다.
파이널라이저는 보통 실행할 코드를 지정하지 않는다.
대신 파이널라이저는 일반적으로 어노테이션과 비슷하게 특정 리소스에 대한 키들의 목록이다.
일부 파이널라이저는 쿠버네티스가 자동으로 지정하지만,
사용자가 직접 지정할 수도 있다.
## 파이널라이저의 작동 방식
매니페스트 파일을 사용해 리소스를 생성하면
`metadata.finalizers` 필드에 파이널라이저를 명시할 수 있다.
리소스를 삭제하려 할 때는
삭제 요청을 처리하는 API 서버가 `finalizers` 필드의 값을 인식하고 다음을 수행한다.
* 삭제를 시작한 시각과 함께 `metadata.deletionTimestamp` 필드를 추가하도록
오브젝트를 수정한다.
* 오브젝트의 `metadata.finalizers` 필드가 비워질 때까지 오브젝트가 제거되지 않도록 한다.
* `202` 상태 코드를 리턴한다(HTTP "Accepted").
이 파이널라이저를 관리하는 컨트롤러는 `metadata.deletionTimestamp`를 설정하는 오브젝트가 업데이트 되었음을 인지하여
오브젝트의 삭제가 요청되었음을 나타낸다.
그런 다음 컨트롤러는 그 리소스에 지정된 파이널라이저의 요구사항을 충족하려 시도한다.
컨트롤러는 파이널라이저 조건이 충족될 때 마다
리소스의 `finalizers` 필드에서 해당 키(key)를 제거한다.
`finalizers` 필드가 비워지면 `deletionTimestamp` 필드가 설정된 오브젝트는 자동으로 삭제된다.
또한 파이널라이저를 사용하여 관리되지 않는 리소스가 삭제되지 않도록 할 수 있다.
파이널라이저의 일반적인 예로는 `퍼시스턴트 볼륨(Persistent Volume)` 오브젝트가 실수로 삭제되는 것을 방지하는 `kubernetes.io/pv-protection`가 있다.
파드가 `퍼시스턴트 볼륨` 오브젝트를 사용 중일 때
쿠버네티스는 `pv-protection` 파이널라이저를 추가한다.
`퍼시스턴트 볼륨`을 삭제하려 하면 `Terminating` 상태가 되지만
파이널라이저가 존재하기 때문에 컨트롤러가 삭제할 수 없다.
파드가 `퍼시스턴트 볼륨`의 사용을 중지하면
쿠버네티스가 `pv-protection` 파이널라이저를 해제하고 컨트롤러는 볼륨을 삭제한다.
## 소유자 참조, 레이블, 파이널라이저 {#소유자-레이블-파이널라이저}
{{<glossary_tooltip term_id="label">}}와 마찬가지로
쿠버네티스에서
[소유자 참조(Owner reference)](/docs/concepts/overview/working-with-objects/owners-dependents/)는
오브젝트 간의 관계를 설명하지만 다른 목적으로 사용된다.
{{<glossary_tooltip term_id="controller">}}가 파드와 같은 오브젝트를 관리할 때
레이블을 사용하여 관련 오브젝트의 그룹에 대한 변경 사항을 추적한다.
예를 들어 {{<glossary_tooltip term_id="job">}}이 하나 이상의 파드를 생성하면
잡 컨트롤러는 해당 파드에 레이블을 적용하고
클러스터 내 동일한 레이블을 갖는 파드에 대한 변경 사항을 추적한다.
또한, 잡 컨트롤러는 이러한 파드에 *소유자 참조*도 추가하여 파드를 생성한 잡을 가리킨다.
이 파드가 실행될 때 잡을 삭제하면
쿠버네티스는 사용자 참조(레이블 대신)를 사용하여
클러스터 내 어떤 파드가 정리되어야 하는지 결정한다.
쿠버네티스는 또한 삭제 대상 리소스에 대한 소유자 참조를 식별할 때
파이널라이저를 처리한다.
경우에 따라 파이널라이저는 종속 오브젝트의 삭제를 차단할 수 있으며
이로 인해 대상 소유자 오브젝트가
완전히 삭제되지 않고 예상보다 오래 유지될 수 있다.
이 경우 대상 소유자 및 종속 객체에 대한
파이널라이저와 소유자 참조를 확인해 원인을 해결해야 한다.
{{<note>}}
오브젝트가 삭제 상태에 있는 경우, 삭제를 계속하려면 파이널라이저를 수동으로 제거해서는 안 된다.
일반적으로 파이널라이저는 특정한 목적으로 가지고 리소스에 추가되므로,
강제로 제거하면 클러스터에 문제가 발생할 수 있다.
이는 파이널라이저의 목적을 이해하고
다른 방법(예를 들어, 일부 종속 객체를 수동으로 정리하는 것)으로
수행될 때만 수행해야 한다.
{{</note>}}
## {{% heading "whatsnext" %}}
* 쿠버네티스 블로그에서
[파이널라이저를 사용해 삭제 제어하기](/blog/2021/05/14/using-finalizers-to-control-deletion/)를 읽어본다.

32
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
View File

@ -8,21 +8,29 @@ card:
---
<!-- overview -->
이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를
어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다.
<!-- body -->
## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를
나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
* 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
* 그 애플리케이션이 이용할 수 있는 리소스
* 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은
그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의
워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의
클러스터에 대해 *의도한 상태* 가 된다.
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면,
[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어,
`kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다.
또한, 여러분은 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를
이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
### 오브젝트 명세(spec)와 상태(status)
@ -48,11 +56,17 @@ spec에 일치되도록 상태를 업데이트하여 3개의 의도한
경우에는 대체 인스턴스를 시작하여)을 통해
spec과 status간의 차이에 대응한다.
오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는,
[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
### 쿠버네티스 오브젝트 기술하기
쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.
쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어,
의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해
(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에
JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에
제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를
변환시켜 준다.
여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다.
@ -81,7 +95,9 @@ deployment.apps/nginx-deployment created
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의
중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는
쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, 파드 API 레퍼런스를 보려면
[`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)를 참조한다.

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

@ -1,6 +1,6 @@
---
# reviewers:
# - mikedanese
title: 레이블과 셀렉터
content_type: concept
weight: 40

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

@ -1,7 +1,7 @@
---
# reviewers:
# - mikedanese
# - thockin
title: 오브젝트 이름과 ID
content_type: concept
weight: 20

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

@ -1,8 +1,8 @@
---
# reviewers:
# - derekwaynecarr
# - mikedanese
# - thockin
title: 네임스페이스
content_type: concept
weight: 30
@ -35,7 +35,7 @@ weight: 30
## 네임스페이스 다루기
네임스페이스의 생성과 삭제는
[네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.
[네임스페이스 관리자 가이드 문서](/ko/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.
{{< note >}}
`kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다.
@ -145,5 +145,5 @@ kubectl api-resources --namespaced=false
## {{% heading "whatsnext" %}}
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
* [신규 네임스페이스 생성](/ko/docs/tasks/administer-cluster/namespaces/#새-네임스페이스-생성하기)에 대해 더 배우기.
* [네임스페이스 삭제](/ko/docs/tasks/administer-cluster/namespaces/#네임스페이스-삭제하기)에 대해 더 배우기.

6
content/ko/docs/concepts/overview/working-with-objects/object-management.md
View File

@ -169,9 +169,9 @@ kubectl apply -R -f configs/
## {{% heading "whatsnext" %}}
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize를 사용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
- [구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

4
content/ko/docs/concepts/policy/limit-range.md
View File

@ -1,4 +1,6 @@
---
# reviewers:
# - nelvadas
title: 리밋 레인지(Limit Range)
content_type: concept
weight: 10
@ -59,5 +61,5 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/ko/docs/tasks/administer-cluster/limit-storage-consumption/#스토리지-요청을-제한하기-위한-리밋레인지-limitrange).
- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).

8
content/ko/docs/concepts/policy/node-resource-managers.md
View File

@ -1,8 +1,8 @@
---
title: 노드 리소스 매니저
# reviewers:
# - derekwaynecarr
# - klueska
title: 노드 리소스 매니저
content_type: 개념
weight: 50
---

124
content/ko/docs/concepts/policy/pid-limiting.md Normal file
View File

@ -0,0 +1,124 @@
---
## reviewers:
## - derekwaynecarr
title: 프로세스 ID 제한 및 예약
content_type: concept
weight: 40
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
쿠버네티스에서 {{< glossary_tooltip term_id="Pod" text="파드" >}}가 사용할 수 있는 프로세스 ID(PID)의 수를
제한할 수 있다.
또한 (파드가 아닌) 운영체제와 데몬이 사용할 용도로 각 {{< glossary_tooltip term_id="node" text="노드" >}}에 대해 할당 가능한
PID의 수를 미리 예약할 수 있다.
<!-- body -->
프로세스 ID(PID)는 노드에서 기본이 되는 리소스이다. 다른 종류의 리소스 상한(limit)을 초과하지 않고도,
태스크의 상한을 초과하게 되는 상황은 일상적이며 사소해 보일 수 있다. 그러나, 이러한 상황은 호스트 머신의
불안정성을 야기할 수 있다.
클러스터 관리자는 클러스터에서 실행 중인 파드가
호스트 데몬(예를 들어, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 또는
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 그리고
잠재적 컨테이너 런타임)이 실행되는 것을 방해하는 PID 소진이
발생하지 않도록 하는 메커니즘이 필요하다.
추가적으로, PID가 동일한 노드의 다른 워크로드에 미치는 영향을 제한하려면
파드 간에 PID를 제한하는 것이 중요하다.
{{< note >}}
특정 리눅스 설치에서는, 운영 체제가 PID 제한을 '32768'과 같은
낮은 기본값으로 설정한다. `/proc/sys/kernel/pid_max`의 값을 높이는 것을 고려하길 바란다.
{{< /note >}}
지정된 파드가 사용할 수 있는 PID 수를 제한하도록 kubelet을 구성할 수 있다.
예를 들어, 노드의 호스트 OS가 최대 '262144' PID를 사용하도록 설정되어 있고
'250' 미만의 파드를 호스팅할 것으로 예상되는 경우, 각 파드에 '1000' PID의 양을 할당하여
해당 노드의 가용 PID의 수를 전부 소비해버리지 않도록 방지할 수 있다. 관리자는
몇 가지 추가 위험을 감수하여 CPU 또는 메모리와 유사한 PID를 오버 커밋할 수 있다.
어느 쪽이든 간에, 하나의 파드가 전체 시스템을 중단시키지는 않을 것이다.
이러한 종류의 리소스 제한은 단순 포크 폭탄(fork bomb)이 전체 클러스터의 작동에 영향을
미치는 것을 방지하는 데 도움이 된다.
관리자는 파드별 PID 제한을 통해 각 파드를 서로에게서 보호할 수 있지만,
해당 호스트에 배정된 모든 파드가 노드 전체에 영향을 미치지 못함을 보장하진 않는다.
또한 파드별 제한은 노드 에이전트 자체를 PID 고갈로부터 보호하지 않는다.
또한 파드에 대한 할당과는 별도로, 노드 오버헤드를 위해 일정량의 PID를
예약할 수 있다. 이는 파드와 해당 컨테이너 외부의 운영 체제 및 기타 장비에서
사용하기 위해 CPU, 메모리 또는 기타 리소스를 예약하는 방식과
유사하다.
PID 제한은 [컴퓨팅 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)
요청 및 제한에서 중요한 개념이다.
하지만 다른 방식으로 명시한다. 파드의 '.spec'에
파드 리소스 제한을 정의하는 대신, kubelet 설정에서
제한을 구성한다. 파드에서 정의하는 PID 제한은 현재 지원되지 않는다.
{{< caution >}}
파드가 배포된 위치에 따라 파드에 적용되는 제한이
다를 수 있다. 간단히 하자면, 모든 노드에서 동일한 PID 리소스 제한 및 예약을
사용하는 것이 가장 쉽다.
{{< /caution >}}
## 노드 PID 제한
쿠버네티스를 사용하면 시스템 사용을 위해 여러 프로세스 ID를 예약할 수 있다.
예약을 구성하려면 `--system-reserved` 및 `--kube-reserved` 명령줄 옵션에서
`pid=<number>` 매개변수를 kubelet에 사용하면 된다.
지정한 값은 지정된 수의 프로세스 ID가
시스템 전체와 Kubernetes 시스템 데몬에 각각 예약됨을
선언한다.
{{< note >}}
쿠버네티스 1.20 버전 이전에서 노드 단위로
PID 리소스 제한을 예약하려면 'SupportNodePidsLimit'
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 작동하도록
설정해야 한다.
{{< /note >}}
## 파드 PID 제한
쿠버네티스를 사용하면 파드에서 실행되는 프로세스 수를 제한할 수 있다.
이 제한을 특정 파드에 대한 리소스 제한으로 구성하는 대신 노드 수준에서 지정한다.
각각의 노드는 다른 PID 제한을 가질 수 있다.
제한을 구성하려면 kubelet에 커맨드라인 매개변수 `--pod-max-pids`를
지정하거나, kubelet [구성 파일](/docs/tasks/administer-cluster/kubelet-config-file/)에서
`PodPidsLimit`을 설정하면 된다.
{{< note >}}
쿠버네티스 1.20 버전 이전에서 파드에 대한 PID 리소스를 제한하려면
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 'SupportPodPidsLimit'이
작동하도록 설정해야 한다.
{{< /note >}}
## PID 기반 축출(eviction)
파드가 오작동하고 비정상적인 양의 리소스를 사용할 때 파드를 종료하게끔 kubelet을 구성할 수 있다.
이 기능을 축출(eviction)이라고 한다. 다양한
축출 신호에 대한 [리소스 부족 처리를 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할
수 있다.
`pid.available` 축출 신호를 사용하여 파드에서 사용하는 PID 수에 대한 임계값을 구성한다.
소프트(soft) 및 하드(hard) 축출 정책을 설정할 수 있다.
그러나 하드 축출 정책을 사용하더라도 PID 수가 매우 빠르게 증가하면,
노드 PID 제한에 도달하여 노드가 여전히 불안정한 상태가 될 수 있다.
축출 신호 값은 주기적으로 계산되는 것이며 제한을 강제하지는 않는다.
PID 제한 - 각 파드와 각 노드는 하드 제한을 설정한다.
제한에 도달하게 되면, 새로운 PID를 가져오려고 할 때 워크로드에 오류가 발생할 것이다.
워크로드가 이러한 장애에 대응하는 방식과 파드에 대한 활성 및 준비성 프로브가
어떻게 구성되었는지에 따라,
파드가 재배포(rescheduling)될 수도 있고 그렇지 않을 수도 있다. 그러나 제한이 올바르게 설정되었다면,
하나의 파드가 오작동할 때 다른 파드 워크로드 및 시스템 프로세스에 PID가 부족하지 않도록
보장할 수 있다.
## {{% heading "whatsnext" %}}
- 자세한 내용은 [PID 제한 개선 문서](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md)를 참고한다.
- 역사적인 맥락을 원한다면,
[Kubernetes 1.14의 안정성 향상을 위한 프로세스 ID 제한](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/)을 참고한다.
- [컨테이너에 대한 리소스 관리](/ko/docs/concepts/configuration/manage-resources-containers/)를 읽는다.
- [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)을 배운다.

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

@ -23,6 +23,7 @@ no_list: true
* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)
* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)
* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)

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

@ -1,8 +1,8 @@
---
# reviewers:
# - davidopp
# - kevin-wangzefeng
# - bsalamat
title: 노드에 파드 할당하기
content_type: concept
weight: 20
@ -11,12 +11,14 @@ weight: 20
<!-- overview -->
특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록
{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다.
특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만
동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 {{< glossary_tooltip text="파드" term_id="pod" >}}를
제한할 수 있다.
이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다.
보통은 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다.
보통은 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가
자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록
노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건을 설정할 필요는 없다.
그러나, 예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는
많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이,
파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다.
@ -29,6 +31,7 @@ weight: 20
* [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드
* [어피니티 / 안티 어피니티](#affinity-and-anti-affinity)
* [nodeName](#nodename) 필드
* [파드 토폴로지 분배 제약 조건](#pod-topology-spread-constraints)
## 노드 레이블 {#built-in-node-labels}
@ -169,7 +172,7 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
`requiredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고,
`preferredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고,
하나에는 `label-1:key-1` 레이블이 있고 다른 하나에는 `label-2:key-2` 레이블이 있으면,
스케줄러는 각 노드의 `weight`를 확인한 뒤
해당 노드에 대한 다른 점수에 가중치를 더하고,
@ -336,16 +339,18 @@ null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이
파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은
상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다.
이러한 규칙을 사용하여, 워크로드 집합이 예를 들면 '동일한 노드'와 같이
동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다.
이러한 규칙을 사용하면, 워크로드 집합이 예를 들면
서로 연관된 두 개의 파드를 동일한 노드에 배치하는 것과 같이 동일하게 정의된 토폴로지와
같은 위치에 배치되도록 쉽게 구성할 수 있다.
redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다.
세 개의 노드로 구성된 클러스터를 상상해 보자. 이 클러스터에서 redis와 같은 인-메모리 캐시를 이용하는 웹 애플리케이션을 실행한다.
또한 이 예에서 웹 애플리케이션과 메모리 캐시 사이의 대기 시간은 될 수 있는 대로 짧아야 한다고 가정하자.
이 때 웹 서버를 가능한 한 캐시와 같은 위치에서 실행되도록 하기 위해
파드간 어피니티/안티-어피니티를 사용할 수 있다.
다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다.
`podAntiAffinity` 규칙은 스케줄러로 하여금
`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다.
`app=store` 레이블을 가진 복수 개의 레플리카를 단일 노드에 배치하지 않게 한다.
이렇게 하여 캐시 파드를 각 노드에 분산하여 생성한다.
```yaml
@ -430,6 +435,10 @@ spec:
| *webserver-1* | *webserver-2* | *webserver-3* |
| *cache-1* | *cache-2* | *cache-3* |
전체적인 효과는 각 캐시 인스턴스를 동일한 노드에서 실행 중인 단일 클라이언트가 액세스하게 될 것 같다는 것이다.
이 접근 방식은 차이(불균형 로드)와 대기 ​​시간을 모두 최소화하는 것을 목표로 한다.
파드간 안티-어피니티를 사용해야 하는 다른 이유가 있을 수 있다.
[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)에서
위 예시와 동일한 기술을 사용해
고 가용성을 위한 안티-어피니티로 구성된 스테이트풀셋의 예시를 확인한다.
@ -468,6 +477,13 @@ spec:
위 파드는 `kube-01` 노드에서만 실행될 것이다.
## 파드 토폴로지 분배 제약 조건
_토폴로지 분배 제약 조건_을 사용하여 지역(regions), 영역(zones), 노드 또는 사용자가 정의한 다른 토폴로지 도메인과 같은 장애 도메인 사이에서 {{< glossary_tooltip text="파드" term_id="Pod" >}}가 클러스터 전체에 분산되는 방식을 제어할 수 있다. 성능, 예상 가용성 또는 전체 활용도를 개선하기 위해 이 작업을 수행할 수 있다.
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에서
작동 방식에 대해 더 자세히 알아볼 수 있다.
## {{% heading "whatsnext" %}}
* [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다.

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

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

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

@ -13,7 +13,7 @@ kubelet은 하나 이상의 파드를 능동적으로 중단시켜
자원을 회수하고 고갈 상황을 방지할 수 있다.
노드-압박 축출 과정에서, kubelet은 축출할 파드의 `PodPhase`를
`Failed`로 설정한다. 이로써 파드가 종료된다.
`Failed`로 설정함으로써 파드가 종료된다.
노드-압박 축출은
[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)과는 차이가 있다.
@ -32,7 +32,7 @@ kubelet은 이전에 설정된 `eviction-max-pod-grace-period` 값을 따른다.
{{<note>}}
kubelet은 최종 사용자 파드를 종료하기 전에
먼저 [노드 수준 자원을 회수](#reclaim-node-resources)하려고 시도한다.
예를 들어, 디스크 자원이 부족하면 먼저 사용하지 않는 컨테이너 이미지를 제거한다.
예를 들어, 디스크 자원이 부족하면 사용하지 않는 컨테이너 이미지를 먼저 제거한다.
{{</note>}}
kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라미터를 사용한다.
@ -44,11 +44,11 @@ kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라
### 축출 신호 {#eviction-signals}
축출 신호는 특정 시점에서 특정 자원의 현재 상태이다.
Kubelet은 노드에서 사용할 수 있는 리소스의 최소량인
kubelet은 노드에서 사용할 수 있는 리소스의 최소량인
축출 임계값과 축출 신호를 비교하여
축출 결정을 내린다.
Kubelet은 다음과 같은 축출 신호를 사용한다.
kubelet은 다음과 같은 축출 신호를 사용한다.
| 축출 신호 | 설명 |
|----------------------|---------------------------------------------------------------------------------------|
@ -61,7 +61,7 @@ Kubelet은 다음과 같은 축출 신호를 사용한다.
이 표에서, `설명` 열은 kubelet이 축출 신호 값을 계산하는 방법을 나타낸다.
각 축출 신호는 백분율 또는 숫자값을 지원한다.
Kubelet은 총 용량 대비 축출 신호의 백분율 값을
kubelet은 총 용량 대비 축출 신호의 백분율 값을
계산한다.
`memory.available` 값은 `free -m`과 같은 도구가 아니라 cgroupfs로부터 도출된다.
@ -82,13 +82,18 @@ kubelet은 다음과 같은 파일시스템 파티션을 지원한다.
1. `imagefs`: 컨테이너 런타임이 컨테이너 이미지 및
컨테이너 쓰기 가능 레이어를 저장하는 데 사용하는 선택적 파일시스템이다.
Kubelet은 이러한 파일시스템을 자동으로 검색하고 다른 파일시스템은 무시한다.
Kubelet은 다른 구성은 지원하지 않는다.
kubelet은 이러한 파일시스템을 자동으로 검색하고 다른 파일시스템은 무시한다.
kubelet은 다른 구성은 지원하지 않는다.
{{<note>}}
일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/architecture/garbage-collection/#containers-images)을 참조한다.
{{</note>}}
아래의 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
| 기존 플래그 | 새로운 플래그 | 이유 |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` 또는 `--eviction-soft` | 기존의 축출 신호가 이미지 가비지 수집을 트리거할 수 있음 |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 축출 회수도 동일한 작업을 수행 |
| `--maximum-dead-containers` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
| `--maximum-dead-containers-per-container` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
| `--minimum-container-ttl-duration` | - | 오래된 로그들이 컨테이너의 컨텍스트 외부에 저장된 이후로 사용되지 않음 |
### 축출 임계값
@ -396,7 +401,7 @@ kubelet의 `memcg` 알림 API가 임계값을 초과할 때 즉시 알림을 받
상태로 간주하고 노드가 메모리 압박을 겪고 있다고 테인트를 표시할 수 있으며, 이는
파드 축출을 유발한다.
더 자세한 사항은 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.
자세한 사항은 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)를 참고한다.
집중적인 I/O 작업을 수행할 가능성이 있는 컨테이너에 대해 메모리 제한량 및 메모리
요청량을 동일하게 설정하여 이 문제를 해결할 수 있다. 해당 컨테이너에 대한 최적의

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

@ -1,8 +1,8 @@
---
# reviewers:
# - dchen1107
# - egernst
# - tallclair
title: 파드 오버헤드
content_type: concept
weight: 30

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

@ -1,7 +1,7 @@
---
# reviewers:
# - davidopp
# - wojtek-t
title: 파드 우선순위(priority)와 선점(preemption)
content_type: concept
weight: 70

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

@ -1,6 +1,6 @@
---
# reviewers:
# - bsalamat
title: 스케줄러 성능 튜닝
content_type: concept
weight: 100

23
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -13,15 +13,16 @@ weight: 40
[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는
{{< glossary_tooltip text="노드" term_id="node" >}} 셋을
(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
_테인트_ 는 그 반대로, 노드가 파드 셋을 제외시킬 수 있다.
_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 [다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다.
톨러레이션은 스케줄을 허용하지만 보장하지는 않는다.
스케줄러는 그 기능의 일부로서
[다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다.
않게 한다. 하나 이상의 테인트가 노드에 적용되는데, 이것은
노드가 테인트를 용인하지 않는 파드를 수용해서는 안 된다는 것을 나타낸다.
<!-- body -->
@ -37,7 +38,7 @@ kubectl taint nodes node1 key1=value1:NoSchedule
`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다.
위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다.
위에서 추가했던 테인트를 제거하려면, 다음을 실행한다.
```shell
kubectl taint nodes node1 key1=value1:NoSchedule-
```
@ -67,7 +68,7 @@ tolerations:
지정하지 않으면 `operator` 의 기본값은 `Equal` 이다.
톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
톨러레이션은, 키와 이펙트가 동일한 경우에 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.
* `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는
* `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다.
@ -266,7 +267,8 @@ tolerations:
## 컨디션(condition)을 기준으로 노드 테인트하기
컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여
[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한
`NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다.
@ -297,5 +299,6 @@ tolerations:
## {{% heading "whatsnext" %}}
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과
어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기

570
content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md Normal file
View File

@ -0,0 +1,570 @@
---
title: 파드 토폴로지 분배 제약 조건
content_type: concept
weight: 40
---
<!-- overview -->
사용자는 _토폴로지 분배 제약 조건_ 을 사용하여
지역(region), 존(zone), 노드 및 기타 사용자 정의 토폴로지 도메인과 같이
장애 도메인으로 설정된 클러스터에 걸쳐
{{< glossary_tooltip text="파드" term_id="Pod" >}}가 분배되는 방식을 제어할 수 있다.
이를 통해 고가용성뿐만 아니라 효율적인 리소스 활용의 목적을 이루는 데에도 도움이 된다.
[클러스터-수준 제약](#cluster-level-default-constraints)을 기본값으로 설정하거나,
개별 워크로드마다 각각의 토폴로지 분배 제약 조건을 설정할 수 있다.
<!-- body -->
## 동기(motivation)
최대 20 노드로 이루어진 클러스터가 있고, 레플리카 수를 자동으로 조절하는
{{< glossary_tooltip text="워크로드" term_id="workload" >}}를
실행해야 하는 상황을 가정해 보자.
파드의 수는 2개 정도로 적을 수도 있고, 15개 정도로 많을 수도 있다.
파드가 2개만 있는 상황에서는, 해당 파드들이 동일 노드에서 실행되는 것은 원치 않을 것이다.
단일 노드 장애(single node failure)로 인해
전체 워크로드가 오프라인이 될 수 있기 때문이다.
이러한 기본적 사용 뿐만 아니라, 고가용성(high availability) 및
클러스터 활용(cluster utilization)으로부터 오는 장점을 워크로드가 누리도록 하는 고급 사용 예시도 존재한다.
워크로드를 스케일 업 하여 더 많은 파드를 실행함에 따라, 중요성이 부각되는 다른 요소도 존재한다.
3개의 노드가 각각 5개의 파드를 실행하는 경우를 가정하자.
각 노드는 5개의 레플리카를 실행하기에 충분한 성능을 갖고 있다.
하지만, 이 워크로드와 통신하는 클라이언트들은
3개의 서로 다른 데이터센터(또는 인프라스트럭처 존(zone))에 걸쳐 존재한다.
이제 단일 노드 장애에 대해서는 덜 걱정해도 되지만, 지연 시간(latency)이 증가하고,
서로 다른 존 간에 네트워크 트래픽을 전송하기 위해 네트워크 비용을 지불해야 한다.
정상적인 동작 중에는 각 인프라스트럭처 존에
비슷한 수의 레플리카가 [스케줄](/ko/docs/concepts/scheduling-eviction/)되고,
클러스터에 문제가 있는 경우 스스로 치유하도록 설정할 수 있다.
파드 토폴로지 분배 제약 조건은 이러한 설정을 할 수 있도록 하는 선언적인 방법을 제공한다.
## `topologySpreadConstraints` 필드
파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 예시는 다음과 같다.
```yaml
---
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
# 토폴로지 분배 제약 조건을 구성한다.
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # 선택 사항이며, v1.24에서 알파 기능으로 도입되었다.
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
### 파드의 다른 필드가 이 아래에 오게 된다.
```
`kubectl explain Pod.spec.topologySpreadConstraints` 명령을 실행하여 이 필드에 대해 좀 더 알아볼 수 있다.
### 분배 제약 조건 정의
하나 또는 다중 `topologySpreadConstraint` 를 정의하여,
kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 고려하며
새로운 파드를 배치할지를 지시할 수 있다. 각 필드는 다음과 같다.
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
이 필드는 필수이며, 0 보다는 커야 한다.
이 필드 값의 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
- `whenUnsatisfiable: DoNotSchedule`을 선택했다면,
`maxSkew`는 대상 토폴로지에서 일치하는 파드 수와
_전역 최솟값(global minimum)_ (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수)
사이의 최대 허용 차이를 나타낸다.
예를 들어, 3개의 존에 각각 2, 4, 5개의 일치하는 파드가 있으면,
전역 최솟값은 2이며 시스템은 이 숫자를 `maxSkew`와 비교한다.
- `whenUnsatisfiable: ScheduleAnyway`를 선택하면,
스케줄러는 차이(skew)를 줄이는 데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다. 이 필드는 선택 사항이다.
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
{{< note >}}
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
이를 사용하려면 `MinDomainsInPodToplogySpread`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
`minDomains`는 `whenUnsatisfiable: DoNotSchedule`일 때에만 지정할 수 있다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
파드 토폴로지 스프레드는 전역 최솟값을 0으로 간주한 뒤, `skew` 계산을 수행한다.
전역 최솟값은 적합한 도메인 내에 매치되는 파드의 최소 수이며,
적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
이 값은 스케줄링에 영향을 미치지 않는다.
- `minDomains`를 명시하지 않으면, 분배 제약 조건은 `minDomains`가 1이라고 가정하고 동작한다.
- **topologyKey** 는 [노드 레이블](#node-labels)의 키(key)이다.
만약 두 노드가 이 키로 레이블이 지정되고 레이블이 동일한 값을 가진다면,
스케줄러는 두 노드를 같은 토폴로지에 있는 것으로 여기게 된다.
스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 파드를 처리하는 방법을 나타낸다.
- `DoNotSchedule`(기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
- `ScheduleAnyway`는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
- **labelSelector** 는 일치하는 파드를 찾는 데 사용된다.
이 레이블 셀렉터와 일치하는 파드의 수를 계산하여
해당 토폴로지 도메인에 속할 파드의 수를 결정한다.
자세한 내용은
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면,
각 제약 조건은 논리 AND 연산으로 조합되며,
kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
### 노드 레이블
토폴로지 분배 제약 조건은 노드 레이블을 이용하여
각 {{< glossary_tooltip text="노드" term_id="node" >}}가 속한 토폴로지 도메인(들)을 인식한다.
예를 들어, 노드가 다음과 같은 레이블을 가질 수 있다.
```yaml
region: us-east-1
zone: us-east-1a
```
{{< note >}}
간결함을 위해, 이 예시에서는
[잘 알려진](/ko/docs/reference/labels-annotations-taints/) 레이블 키인
`topology.kubernetes.io/zone` 및 `topology.kubernetes.io/region`을 사용하지 않는다.
그러나 그렇더라도, 아래에 등장하는 프라이빗(비공인된) 레이블 키인 `region` 및 `zone`보다는
위와 같은 공인된 레이블 키를 사용하는 것을 권장한다.
다양한 각 상황에 대해, 프라이빗 레이블 키의 의미가
모두 우리의 생각과 같을 것이라고 가정할 수는 없다.
{{< /note >}}
각각 다음과 같은 레이블을 갖는 4개의 노드로 구성된 클러스터가 있다고 가정한다.
```
NAME STATUS ROLES AGE VERSION LABELS
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
```
그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
{{<mermaid>}}
graph TB
subgraph "zoneB"
n3(Node3)
n4(Node4)
end
subgraph "zoneA"
n1(Node1)
n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
## 일관성(consistency)
그룹 내의 모든 파드에는 동일한 파드 토폴로지 분배 제약 조건을 설정해야 한다.
일반적으로, 디플로이먼트와 같은 워크로드 컨트롤러를 사용하는 경우,
파드 템플릿이 이 사항을 담당한다.
여러 분배 제약 조건을 혼합하는 경우, 쿠버네티스는 해당 필드의 API 정의를 따르기는 하지만,
동작이 복잡해질 수 있고 트러블슈팅이 덜 직관적이게 된다.
동일한 토폴로지 도메인(예: 클라우드 공급자 리전)에 있는 모든 노드가
일관적으로 레이블되도록 하는 메카니즘이 필요하다.
각 노드를 수동으로 레이블하는 것을 피하기 위해,
대부분의 클러스터는 `topology.kubernetes.io/hostname`와 같은 잘 알려진 레이블을 자동으로 붙인다.
이용하려는 클러스터가 이를 지원하는지 확인해 본다.
## 토폴로지 분배 제약 조건 예시
### 예시: 단수 토폴로지 분배 제약 조건 {#example-one-topologyspreadconstraint}
`foo:bar` 가 레이블된 3개의 파드가 4개 노드를 가지는 클러스터의
node1, node2 및 node3에 각각 위치한다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
신규 파드가 기존 파드와 함께 여러 존에 걸쳐 균등하게 분배되도록 하려면,
다음과 같은 매니페스트를 사용할 수 있다.
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
위의 매니페스트에서, `topologyKey: zone`이 의미하는 것은 `zone: <any value>`로 레이블된
노드에 대해서만 균등한 분배를 적용한다는 뜻이다(`zone` 레이블이 없는 노드는 무시된다).
`whenUnsatisfiable: DoNotSchedule` 필드는 만약 스케줄러가 신규 파드에 대해 제약 조건을
만족하는 스케줄링 방법을 찾지 못하면 이 신규 파드를 pending 상태로 유지하도록 한다.
만약 스케줄러가 이 신규 파드를 `A` 존에 배치하면 파드 분포는 `[3, 1]`이 된다.
이는 곧 실제 차이(skew)가 2(`3-1`)임을 나타내는데, 이는 `maxSkew: 1`을 위반하게 된다.
이 예시에서 제약 조건과 상황을 만족하려면,
신규 파드는 `B` 존의 노드에만 배치될 수 있다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
또는
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n3
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
사용자는 파드 스펙을 조정하여 다음과 같은 다양한 요구사항을 충족할 수 있다.
- `maxSkew` 를 더 큰 값(예: `2`)으로 변경하여
신규 파드가 `A` 존에도 배치할 수 있도록 한다.
- `topologyKey`를 `node`로 변경하여 파드가 존이 아닌 노드에 걸쳐 고르게 분산되도록 한다.
위의 예시에서, 만약 `maxSkew`를 `1`로 유지한다면,
신규 파드는 오직 `node4`에만 배치될 수 있다.
- `whenUnsatisfiable: DoNotSchedule`를 `whenUnsatisfiable: ScheduleAnyway`로 변경하면
신규 파드가 항상 스케줄링되도록 보장할 수 있다(다른 스케줄링 API를 충족한다는 가정 하에).
그러나, 매칭되는 파드의 수가 적은 토폴로지 도메인에 배치되는 것이 선호된다.
(이 선호도는 리소스 사용 비율과 같은 다른 내부 스케줄링 우선순위와 함께 정규화된다는 것을
알아두자.)
### 예시: 다중 토폴로지 분배 제약 조건 {#example-multiple-topologyspreadconstraints}
이 예시는 위의 예시에 기반한다. `foo:bar` 가 레이블된 3개의 파드가
4개 노드를 가지는 클러스터의 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
사용자는 2개의 토폴로지 분배 제약 조건을 사용하여
노드 및 존 기반으로 파드가 분배되도록 제어할 수 있다.
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
이 경우에는, 첫 번째 제약 조건에 부합하려면, 신규 파드는 오직 `B` 존에만 배치될 수 있다.
한편 두 번째 제약 조건에 따르면 신규 파드는 오직 `node4` 노드에만 배치될 수 있다.
스케줄러는 모든 정의된 제약 조건을 만족하는 선택지만 고려하므로,
유효한 유일한 선택지는 신규 파드를 `node4`에 배치하는 것이다.
### 예시: 상충하는 토폴로지 분배 제약 조건 {#example-conflicting-topologyspreadconstraints}
다중 제약 조건이 서로 충돌할 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 존에 걸쳐 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p4(Pod) --> n3(Node3)
p5(Pod) --> n3
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n1
p3(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
만약
[`two-constraints.yaml`](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/topology-spread-constraints/two-constraints.yaml)
(위 예시의 매니페스트)을
**이** 클러스터에 적용하면,
`mypod` 파드가 `Pending` 상태로 유지되는 것을 볼 수 있을 것이다.
이러한 이유는, 첫 번째 제약 조건을 충족하려면 `mypod` 파드는 `B` 존에만 배치될 수 있지만,
두 번째 제약 조건에 따르면 `mypod` 파드는 `node2` 노드에만 스케줄링될 수 있기 때문이다.
두 제약 조건의 교집합이 공집합이므로, 스케줄러는 파드를 배치할 수 없다.
이 상황을 극복하기 위해, `maxSkew` 값을 증가시키거나,
제약 조건 중 하나를 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 수정할 수 있다.
상황에 따라, 기존 파드를 수동으로 삭제할 수도 있다.
예를 들어, 버그픽스 롤아웃이 왜 진행되지 않는지 트러블슈팅하는 상황에서 이 방법을 활용할 수 있다.
#### 노드 어피니티(Affinity) 및 노드 셀렉터(Selector)와의 상호 작용
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우,
부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
### 예시: 토폴로지 분배 제약조건과 노드 어피니티 {#example-topologyspreadconstraints-with-nodeaffinity}
5개의 노드를 가지는 클러스터가 A 존에서 C 존까지 걸쳐 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
그리고 `C` 존은 파드 배포에서 제외해야 한다는 사실을 사용자가 알고 있다고 가정한다.
이 경우에, 다음과 같이 매니페스트를 작성하여, `mypod` 파드가 `C` 존 대신 `B` 존에 배치되도록 할 수 있다.
유사하게, 쿠버네티스는 `spec.nodeSelector` 필드도 고려한다.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
## 암묵적 규칙
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 동일한 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다.
이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 `maxSkew` 계산에 영향을 미치지 않는다.
위의 예시에서, `node1` 노드는 "zone" 레이블을 가지고 있지 않다고 가정하면,
파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 `A` 존으로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다.
위의 예시에서, **잘못 타이핑된** `zone-typo: zoneC` 레이블을 갖는 `node5` 노드가 있다고 가정하자(`zone` 레이블은 설정되지 않음).
`node5` 노드가 클러스터에 편입되면, 해당 노드는 무시되고
이 워크로드의 파드는 해당 노드에 스케줄링되지 않는다.
- 신규 파드의 `topologySpreadConstraints[*].labelSelector`가 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다.
위의 예시에서, 신규 파드의 레이블을 제거해도,
제약 조건이 여전히 충족되기 때문에 이 파드는 `B` 존의 노드에 배치될 수 있다.
그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다.
여전히 `A` 존은 `foo: bar` 레이블을 가지는 2개의 파드를 가지고 있고,
`B` 존도 `foo: bar` 레이블을 가지는 1개의 파드를 가지고 있다.
만약 결과가 예상과 다르다면,
워크로드의 `topologySpreadConstraints[*].labelSelector`를 파드 템플릿의 레이블과 일치하도록 업데이트한다.
## 클러스터 수준의 기본 제약 조건
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다.
기본 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
- `.spec.topologySpreadConstraints` 에 어떠한 제약 조건도 정의되어 있지 않는 경우.
- 서비스, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet), 또는 레플리케이션컨트롤러(ReplicationController)에 속해있는 경우.
기본 제약 조건은
[스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)내의 플러그인 인자 중 하나로 설정할 수 있다.
제약 조건은 [위에서 설명한 것과 동일한 API](#api)를 이용하여 정의되는데,
다만 `labelSelector`는 비워 두어야 한다.
셀렉터는 파드가 속한 서비스, 레플리카셋, 스테이트풀셋, 또는 레플리케이션 컨트롤러를 바탕으로 계산한다.
예시 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
기본적으로 비활성화되어 있다.
비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
{{< /note >}}
### 내장 기본 제약 조건 {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
파드 토폴로지 분배에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
kube-scheduler는 다음과 같은 기본 토폴로지 제약이 설정되어 있는 것처럼 동작한다.
```yaml
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
```
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은
기본적으로 비활성화되어 있다.
{{< note >}}
`PodTopologySpread` 플러그인은
분배 제약 조건에 지정된 토폴로지 키가 없는 노드에 점수를 매기지 않는다.
이로 인해 기본 토폴로지 제약을 사용하는 경우의
레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
레이블 세트가 **둘 다** 설정되지 않을 것으로 예상되는 경우,
쿠버네티스 기본값을 사용하는 대신 자체 제약 조건을 정의하자.
{{< /note >}}
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
`PodTopologySpread` 플러그인 구성에서 `defaultingType` 을 `List` 로 설정하고
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## 파드어피니티(PodAffinity) 및 파드안티어피니티(PodAntiAffinity)와의 비교 {#comparison-with-podaffinity-podantiaffinity}
쿠버네티스에서, [파드간 어피니티 및 안티 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)는
파드가 다른 파드에 서로 어떤 연관 관계를 지니며 스케줄링되는지를 제어하며,
이는 파드들이 서로 더 밀집되도록 하거나 흩어지도록 하는 것을 의미한다.
`podAffinity`
: 파드를 끌어당긴다. 조건이 충족되는 토폴로지 도메인에는
원하는 수의 파드를 얼마든지 채울 수 있다.
`podAntiAffinity`
: 파드를 밀어낸다.
이를 `requiredDuringSchedulingIgnoredDuringExecution` 모드로 설정하면
각 토폴로지 도메인에는 하나의 파드만 스케줄링될 수 있다.
반면 `preferredDuringSchedulingIgnoredDuringExecution`로 설정하면 제약 조건이 강제성을 잃게 된다.
더 세밀한 제어를 위해,
토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를 분배할 수 있고,
이를 통해 고 가용성 또는 비용 절감을 달성할 수 있다.
이는 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은
파드 토폴로지 분배 제약 조건에 대한 개선 제안의
[동기(motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) 섹션을 참고한다.
## 알려진 제한사항
- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다.
예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다.
[Descheduler](https://github.com/kubernetes-sigs/descheduler)와 같은 도구를 사용하여
파드 분포를 다시 균형있게 만들 수 있다.
- 테인트된(tainted) 노드에 매치된 파드도 계산에 포함된다.
[이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
- 스케줄러는 클러스터가 갖는 모든 존 또는 다른 토폴로지 도메인에 대한 사전 지식을 갖고 있지 않다.
이 정보들은 클러스터의 기존 노드로부터 획득된다.
이로 인해 오토스케일된 클러스터에서 문제가 발생할 수 있는데,
예를 들어 노드 풀(또는 노드 그룹)이 0으로 스케일 다운되고,
클러스터가 다시 스케일 업 되기를 기대하는 경우,
해당 토폴로지 도메인은 적어도 1개의 노드가 존재하기 전에는 고려가 되지 않을 것이다.
이를 극복하기 위해, 파드 토폴로지 분배 제약 조건과
전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는
클러스터 오토스케일링 도구를 이용할 수 있다.
## {{% heading "whatsnext" %}}
- [블로그: PodTopologySpread 소개](/blog/2020/05/introducing-podtopologyspread/)에서는
`maxSkew` 에 대해 자세히 설명하고, 몇 가지 고급 사용 예제를 제공한다.
- 파드 API 레퍼런스의
[스케줄링](/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling) 섹션을 읽어 본다.

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

@ -23,14 +23,15 @@ weight: 50
## 전송 보안
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는 첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다. 일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다. 포트번호는 `--secure-port` 플래그를 통해, 수신 대기 IP 주소는 `--bind-address` 플래그를 통해 변경될 수 있다.
API 서버는 인증서를 제시한다.
이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
API 서버의 인증서에 대한 루트 인증서를 포함하며,
시스템 기본 루트 인증서 대신 사용된다.
`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
이러한 인증서는 사설 인증 기관(CA)에 기반하여 서명되거나, 혹은 공인 CA와 연결된 공개키 인프라스트럭처에 기반한다.
인증서와 그에 해당하는 개인키는 각각 `--tls-cert-file`과 `--tls-private-key-file` 플래그를 통해 지정한다.
만약 클러스터가 사설 인증 기관을 사용한다면,
해당 CA 인증서를 복사하여 클라이언트의 `~/.kube/config` 안에 구성함으로써
연결을 신뢰하고 누군가 중간에 가로채지 않았음을 보장해야 한다.
클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.
@ -137,40 +138,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다.
## API 서버 포트와 IP
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
1. `로컬호스트 포트`:
- 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
- TLS가 없다.
- 기본 포트는 8080이다.
- 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈을 **우회한다**.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 호스트 접근 요구로부터 보호를 받는다.
2. `보안 포트`:
- 가능한 항상 사용하는 것이 좋다.
- TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
- 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
- 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈에 의해 처리된다.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 인증 및 인가 모듈을 실행한다.
## {{% heading "whatsnext" %}}
인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
- [인증하기](/docs/reference/access-authn-authz/authentication/)
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/)
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/ko/docs/reference/access-authn-authz/bootstrap-tokens/)
- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/)
- [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [인가](/ko/docs/reference/access-authn-authz/authorization/)

6
content/ko/docs/concepts/security/overview.md
View File

@ -1,6 +1,6 @@
---
# reviewers:
# - zparnold
title: 클라우드 네이티브 보안 개요
description: >
클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델
@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
쿠버네티스 보안 주제에 관련한 내용들을 배워보자.
* [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
* [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)

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

@ -1,7 +1,7 @@
---
# reviewers:
# - pweil-
# - tallclair
title: 파드 시큐리티 폴리시
content_type: concept
weight: 30
@ -11,9 +11,13 @@ weight: 30
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, v1.25에서 제거될 예정이다.
파드시큐리티폴리시는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)으로 대체되었다.
사용 중단에 대한 상세 사항은 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
{{< caution >}}
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, **v1.25에서 제거될 예정**이다.
[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 혹은 써드파티 어드미션 플러그인으로 대체하는 것을 권장한다.
상세 가이드는 [파드시큐리티폴리시를 파드 시큐리티 어드미션 컨트롤러로 대체하기](/docs/tasks/configure-pod-container/migrate-from-psp/)를 참조한다.
사용 중단에 대한 상세 사항은
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
{{< /caution >}}
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.
@ -23,10 +27,11 @@ weight: 30
## 파드 시큐리티 폴리시란?
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
리소스이다.
[파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
조건 셋을 정의한다. 관리자는
다음을 제어할 수 있다.
조건 셋을 정의한다.
관리자는 다음을 제어할 수 있다.
| 제어 측면 | 필드 이름 |
| ----------------------------------------------------| ------------------------------------------- |
@ -150,14 +155,17 @@ RBAC 바인딩에 대한 자세한 예는,
text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다.
이 변경에 대한 상세사항은
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
다음 가이드라인을 참조하여 파드시큐리티폴리시를
새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
1. 파드시큐리티폴리시를 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
1. 파드시큐리티폴리시를
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
2. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
1. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여
파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.
```yaml
@ -182,16 +190,16 @@ text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되
### 문제 해결
- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
API 서버 접근 제어에 대한 자세한 내용은
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
만들 수 있는 권한을 부여할 수 있다.
보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
API 서버 접근 제어에 대한 자세한 내용은
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
만들 수 있는 권한을 부여할 수 있다.
컨트롤러 관리자 권한 구성에 대한 자세한 내용은
[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고하기 바란다.
컨트롤러 관리자 권한 구성에 대한 자세한 내용은
[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고한다.
## 정책 순서
@ -206,6 +214,9 @@ API 서버 접근 제어에 대한 자세한 내용은
2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시
(이름순)가 선택된다.
파드시큐리티폴리시에 대해 파드의 유효성이 검증되면,
파드시큐리티폴리시의 이름을 어노테이션 값으로 사용하는 [`kubernetes.io/psp` 어노테이션]이 파드에 추가된다.
{{< note >}}
업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만
파드의 유효성을 검사하는 데 사용된다.
@ -237,8 +248,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
### 정책과 파드 생성
파일에서 예제 파드시큐리티폴리시 오브젝트를 정의한다. 이는 특권있는 파드를
만들지 못하게 하는 정책이다.
이는 특권있는 파드를 만들지 못하게 하는 정책이다.
파드시큐리티폴리시 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.
@ -247,7 +257,7 @@ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n
그리고 kubectl로 생성한다.
```shell
kubectl-admin create -f example-psp.yaml
kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml
```
이제 권한이 없는 사용자로서 간단한 파드를 생성해보자.
@ -276,6 +286,11 @@ Error from server (Forbidden): error when creating "STDIN": pods "pause" is forb
```shell
kubectl-user auth can-i use podsecuritypolicy/example
```
결과는 다음과 같다:
```
no
```
@ -292,14 +307,27 @@ kubectl-admin create role psp:unprivileged \
--verb=use \
--resource=podsecuritypolicy \
--resource-name=example
role "psp:unprivileged" created
```
```
role "psp:unprivileged" created
```
```shell
kubectl-admin create rolebinding fake-user:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created
```
```
rolebinding "fake-user:psp:unprivileged" created
```
```shell
kubectl-user auth can-i use podsecuritypolicy/example
```
```
yes
```
@ -324,7 +352,20 @@ EOF
pod "pause" created
```
예상대로 작동한다! 그러나 특권있는 파드를 만들려는 시도는 여전히
예상대로 작동한다!
새로 생성된 파드시큐리티폴리시에 대해서도 파드가 유효한지 검증한다:
```shell
kubectl-user get pod pause -o yaml | grep kubernetes.io/psp
```
결과는 다음과 같다:
```
kubernetes.io/psp: example
```
그러나 특권있는 파드를 만들려는 시도는 여전히
거부되어야 한다.
```shell
@ -360,12 +401,24 @@ kubectl-user delete pod pause
```shell
kubectl-user create deployment pause --image=k8s.gcr.io/pause
```
```none
deployment "pause" created
```
```shell
kubectl-user get pods
No resources found.
```
```
No resources found.
```
```shell
kubectl-user get events | head -n 2
```
```
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
```
@ -386,6 +439,9 @@ forbidden: no providers available to validate pod request` 오류가
kubectl-admin create rolebinding default:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:default
```
```none
rolebinding "default:psp:unprivileged" created
```
@ -394,6 +450,9 @@ rolebinding "default:psp:unprivileged" created
```shell
kubectl-user get pods --watch
```
```none
NAME READY STATUS RESTARTS AGE
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
@ -407,6 +466,9 @@ pause-7774d79b5-qrgcb 1/1 Running 0 2s
```shell
kubectl-admin delete ns psp-example
```
```
namespace "psp-example" deleted
```
@ -415,6 +477,9 @@ namespace "psp-example" deleted
```shell
kubectl-admin delete psp example
```
```
podsecuritypolicy "example" deleted
```
@ -431,7 +496,8 @@ podsecuritypolicy "example" deleted
{{< codenew file="policy/restricted-psp.yaml" >}}
더 많은 예제는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다.
더 많은 예제는
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/#정책-초기화)을 본다.
## 정책 레퍼런스
@ -511,7 +577,8 @@ podsecuritypolicy "example" deleted
readOnly: true # 읽기 전용 마운트만 허용
```
{{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
{{< warning >}}
호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.
@ -624,8 +691,7 @@ spec:
**DefaultAddCapabilities** - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다.
도커 런타임을 사용할 때 기본 기능 목록은
[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를
참고하길 바란다.
[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를 참고한다.
### SELinux
@ -658,8 +724,9 @@ spec:
쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서
`seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을
제어](/docs/tutorials/security/seccomp/)할 수 있다. 이전 버전에서는, 파드에
어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
제어](/docs/tutorials/security/seccomp/)할 수 있다.
이전 버전에서는, 파드에 어노테이션을 추가하여 seccomp를 제어했다.
두 버전에서 동일한 파드시큐리티폴리시를 사용하여
이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.
**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에
@ -692,11 +759,13 @@ spec:
기본적으로 모든 안전한 sysctls가 허용된다.
- `forbiddenSysctls` - 특정 sysctls를 제외한다. 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. 모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다.
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
- `forbiddenSysctls` - 특정 sysctls를 제외한다.
목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다.
모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다.
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한
기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
[Sysctl 문서](
/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
[Sysctl 문서](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
## {{% heading "whatsnext" %}}
@ -704,6 +773,8 @@ spec:
미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서
파드시큐리티폴리시의 미래에 대해 알아본다.
- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)을 참조한다.
- API 세부 정보는
[파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
- API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.

523
content/ko/docs/concepts/security/pod-security-standards.md Normal file
View File

@ -0,0 +1,523 @@
---
# reviewers:
# -
title: 파드 시큐리티 스탠다드
description: >
파드 시큐리티 스탠다드에 정의된 여러 가지 정책 레벨에 대한 세부사항
content_type: concept
weight: 10
---
<!-- overview -->
파드 시큐리티 스탠다드에서는 보안 범위를 넓게 다루기 위해 세 가지 _정책을_ 정의한다.
이러한 정책은 _점증적이며_ 매우 허용적인 것부터 매우 제한적인 것까지 있다.
이 가이드는 각 정책의 요구사항을 간략히 설명한다.
| 프로필 | 설명 |
| ------ | ----------- |
| <strong style="white-space: nowrap">특권(Privileged)</strong> | 무제한 정책으로, 가장 넓은 범위의 권한 수준을 제공한다. 이 정책은 알려진 권한 상승(privilege escalations)을 허용한다. |
| <strong style="white-space: nowrap">기본(Baseline)</strong> | 알려진 권한 상승을 방지하는 최소한의 제한 정책이다. 기본(최소로 명시된) 파드 구성을 허용한다. |
| <strong style="white-space: nowrap">제한(Restricted)</strong> | 엄격히 제한된 정책으로 현재 파드 하드닝 모범 사례를 따른다. |
<!-- body -->
## 프로필 세부사항
### 특권(Privileged) {#privileged}
**_특권_ 정책은 의도적으로 열려있으며 전적으로 제한이 없다.** 이러한 종류의 정책은
권한이 있고 신뢰할 수 있는 사용자가 관리하는 시스템 및 인프라 수준의 워크로드를 대상으로 한다.
특권 정책은 제한 사항이 없는 것으로 정의한다. 기본으로 허용하는 메커니즘(예를 들면, gatekeeper)은 당연히 특권 정책일 수 있다.
반대로, 기본적으로 거부하는 메커니즘(예를 들면, 파드 시큐리티 폴리시)의 경우 특권 정책은
모든 제한 사항을 비활성화해야 한다.
### 기본(Baseline) {#baseline}
**_기본_ 정책은 알려진 권한 상승을 방지하면서 일반적인 컨테이너 워크로드에 대해 정책 채택을 쉽게 하는 것을 목표로 한다.**
이 정책은 일반적인(non-critical) 애플리케이션의 운영자 및 개발자를 대상으로 한다.
아래 명시한 제어 방식은 다음과 같이
강행되거나 금지되어야 한다.
{{< note >}}
다음 표에서 와일드카드(`*`)는 리스트에 포함된 모든 요소들을 가리킨다.
예를 들어, `spec.containers[*].securityContext`는 시큐리티 컨텍스트 오브젝트에 _정의되어 있는 모든 컨테이너를_ 가리킨다.
정의된 컨테이너 중 하나라도 요구사항을 충족시키지 못한다면, 파드 전체가
검증 과정에서 실패한다.
{{< /note >}}
<table>
<caption style="display:none">기본(Baseline) 정책 명세서</caption>
<tbody>
<tr>
<th>제어</th>
<th>정책</th>
</tr>
<tr>
<td style="white-space: nowrap">호스트 프로세스</td>
<td>
<p>윈도우 파드는 <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">호스트 프로세스 컨테이너</a>를 실행할 권한을 제공하며, 이는 윈도우 노드에 대한 특권 접근을 가능하게 한다. 기본 정책에서의 호스트에 대한 특권 접근은 허용되지 않는다. {{< feature-state for_k8s_version="v1.23" state="beta" >}}</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
<li><code>spec.containers[*].securityContext.windowsOptions.hostProcess</code></li>
<li><code>spec.initContainers[*].securityContext.windowsOptions.hostProcess</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>false</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">호스트 네임스페이스</td>
<td>
<p>호스트 네임스페이스 공유는 금지된다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.hostNetwork</code></li>
<li><code>spec.hostPID</code></li>
<li><code>spec.hostIPC</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>false</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">특권 컨테이너</td>
<td>
<p>특권 파드(Privileged Pods)는 대부분의 보안 메커니즘을 비활성화하므로 금지된다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.privileged</code></li>
<li><code>spec.initContainers[*].securityContext.privileged</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.privileged</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>false</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">기능(Capabilities)</td>
<td>
<p>아래 명시되지 않은 부가 기능을 추가하는 작업은 금지된다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>AUDIT_WRITE</code></li>
<li><code>CHOWN</code></li>
<li><code>DAC_OVERRIDE</code></li>
<li><code>FOWNER</code></li>
<li><code>FSETID</code></li>
<li><code>KILL</code></li>
<li><code>MKNOD</code></li>
<li><code>NET_BIND_SERVICE</code></li>
<li><code>SETFCAP</code></li>
<li><code>SETGID</code></li>
<li><code>SETPCAP</code></li>
<li><code>SETUID</code></li>
<li><code>SYS_CHROOT</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">호스트 경로(hostPath) 볼륨</td>
<td>
<p>호스트 경로 볼륨은 금지된다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.volumes[*].hostPath</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">호스트 포트</td>
<td>
<p>호스트 포트는 허용되지 않아야 하며, 또는 적어도 알려진 목록 범위내로 제한되어야 한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].ports[*].hostPort</code></li>
<li><code>spec.initContainers[*].ports[*].hostPort</code></li>
<li><code>spec.ephemeralContainers[*].ports[*].hostPort</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li>Known list</li>
<li><code>0</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">AppArmor</td>
<td>
<p>지원되는 호스트에서는, <code>runtime/default</code> AppArmor 프로필이 기본으로 적용된다. 기본 정책은 기본 AppArmor 프로필이 오버라이드 및 비활성화되는 것을 방지해야 하며, 또는 허용된 프로필에 한해서만 오버라이드 되도록 제한해야 한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>runtime/default</code></li>
<li><code>localhost/*</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">SELinux</td>
<td>
<p>SELinux 타입을 설정하는 것은 제한되며, 맞춤 SELinux 사용자 및 역할 옵션을 설정하는 것은 금지되어 있다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.seLinuxOptions.type</code></li>
<li><code>spec.containers[*].securityContext.seLinuxOptions.type</code></li>
<li><code>spec.initContainers[*].securityContext.seLinuxOptions.type</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.type</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/""</li>
<li><code>container_t</code></li>
<li><code>container_init_t</code></li>
<li><code>container_kvm_t</code></li>
</ul>
<hr />
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.seLinuxOptions.user</code></li>
<li><code>spec.containers[*].securityContext.seLinuxOptions.user</code></li>
<li><code>spec.initContainers[*].securityContext.seLinuxOptions.user</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.user</code></li>
<li><code>spec.securityContext.seLinuxOptions.role</code></li>
<li><code>spec.containers[*].securityContext.seLinuxOptions.role</code></li>
<li><code>spec.initContainers[*].securityContext.seLinuxOptions.role</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.seLinuxOptions.role</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/""</li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap"><code>/proc</code> 마운트 타입</td>
<td>
<p>기본 <code>/proc</code> 마스크는 공격 가능 영역을 최소화하기 위해 설정되고 필수이다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.procMount</code></li>
<li><code>spec.initContainers[*].securityContext.procMount</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.procMount</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>Default</code></li>
</ul>
</td>
</tr>
<tr>
<td>Seccomp</td>
<td>
<p>Seccomp 프로필은 <code>Unconfined</code>으로 설정하면 안된다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.seccompProfile.type</code></li>
<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>RuntimeDefault</code></li>
<li><code>Localhost</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">Sysctls</td>
<td>
<p>Sysctls는 보안 메커니즘을 비활성화 시키거나 호스트에 위치한 모든 컨테이너에 영향을 미칠 수 있으며, 허용된 "안전한" 서브넷을 제외한 곳에서는 허용되지 않아야 한다. 컨테이너 또는 파드 네임스페이스에 속해 있거나, 같은 노드 내의 다른 파드 및 프로세스와 격리된 상황에서만 sysctl 사용이 안전하다고 간주한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.sysctls[*].name</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>kernel.shm_rmid_forced</code></li>
<li><code>net.ipv4.ip_local_port_range</code></li>
<li><code>net.ipv4.ip_unprivileged_port_start</code></li>
<li><code>net.ipv4.tcp_syncookies</code></li>
<li><code>net.ipv4.ping_group_range</code></li>
</ul>
</td>
</tr>
</tbody>
</table>
### 제한(Restricted) {#restricted}
**_제한_ 정책은 일부 호환성을 희생하면서 현재 사용되고 있는 파드 하드닝 모범 사례 시행하는 것을 목표로 한다.**
보안이 중요한 애플리케이션의 운영자 및 개발자는 물론 신뢰도가 낮은 사용자도 대상으로 한다.
아래에 나열된 제어 방식은
강제되거나 금지되어야 한다.
{{< note >}}
다음 표에서 와일드카드(`*`)는 리스트에 포함된 모든 요소들을 가리킨다.
예를 들어, `spec.containers[*].securityContext`는 시큐리티 컨텍스트 오브젝트에 _정의되어 있는 모든 컨테이너를_ 가리킨다.
나열된 컨테이너 중 하나라도 요구사항을 충족시키지 못한다면, 파드 전체가
검증에 실패한다.
{{< /note >}}
<table>
<caption style="display:none">제한 정책 명세서</caption>
<tbody>
<tr>
<td><strong>제어</strong></td>
<td><strong>정책</strong></td>
</tr>
<tr>
<td colspan="2"><em>기본 프로필에 해당하는 모든 요소</em></td>
</tr>
<tr>
<td style="white-space: nowrap">볼륨 타입</td>
<td>
<p>제한 정책은 다음과 같은 볼륨 타입만 허용한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.volumes[*]</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<code>spec.volumes[*]</code> 목록에 속한 모든 아이템은 다음 필드 중 하나를 null이 아닌 값으로 설정해야 한다.
<ul>
<li><code>spec.volumes[*].configMap</code></li>
<li><code>spec.volumes[*].csi</code></li>
<li><code>spec.volumes[*].downwardAPI</code></li>
<li><code>spec.volumes[*].emptyDir</code></li>
<li><code>spec.volumes[*].ephemeral</code></li>
<li><code>spec.volumes[*].persistentVolumeClaim</code></li>
<li><code>spec.volumes[*].projected</code></li>
<li><code>spec.volumes[*].secret</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">권한 상승(v1.8+)</td>
<td>
<p>권한 상승(예를 들어, set-user-ID 또는 set-group-ID 파일 모드를 통한)은 허용되지 않아야 한다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.allowPrivilegeEscalation</code></li>
<li><code>spec.initContainers[*].securityContext.allowPrivilegeEscalation</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li><code>false</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">루트가 아닌 권한으로 실행</td>
<td>
<p>컨테이너는 루트가 아닌 사용자 권한으로 실행되어야 한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.runAsNonRoot</code></li>
<li><code>spec.containers[*].securityContext.runAsNonRoot</code></li>
<li><code>spec.initContainers[*].securityContext.runAsNonRoot</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.runAsNonRoot</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li><code>true</code></li>
</ul>
<small>
pod-level에서 <code>spec.securityContext.runAsNonRoot</code>가 <code>true</code>로 설정되면
컨테이너 필드는 undefined/<code>nil</code>로 설정될 수 있다.
</small>
</td>
</tr>
<tr>
<td style="white-space: nowrap">루트가 아닌 사용자로 실행(v1.23+)</td>
<td>
<p>컨테이너에서는 <tt>runAsUser</tt> 값을 0으로 설정하지 않아야 한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.runAsUser</code></li>
<li><code>spec.containers[*].securityContext.runAsUser</code></li>
<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>any non-zero value</li>
<li><code>undefined/null</code></li>
</ul>
</td>
</tr>
<tr>
<td style="white-space: nowrap">Seccomp(v1.19+)</td>
<td>
<p>Seccomp 프로필은 다음과 같은 값으로 설정되어야 한다.<code>Unconfined</code> 프로필 및 프로필의 <em>absence</em>는 금지되어 있다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.seccompProfile.type</code></li>
<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li><code>RuntimeDefault</code></li>
<li><code>Localhost</code></li>
</ul>
<small>
pod-level의 <code>spec.securityContext.seccompProfile.type</code> 필드가 적절하게 설정되면,
컨테이너 필드는 undefined/<code>nil</code>로 설정될 수 있다.
모든 컨테이너 레벨 필드가 설정되어 있다면,
pod-level 필드는 undefined/<code>nil</code>로 설정될 수 있다.
</small>
</td>
</tr>
<tr>
<td style="white-space: nowrap">능력(Capabilities) (v1.22+)</td>
<td>
<p>
컨테이너는 <code>ALL</code> 능력을 내려놓아야 하며,
<code>NET_BIND_SERVICE</code> 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.capabilities.drop</code></li>
<li><code>spec.initContainers[*].securityContext.capabilities.drop</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.capabilities.drop</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li><code>ALL</code>을 포함하고 있는 모든 능력 리스트</li>
</ul>
<hr />
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
</ul>
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li><code>NET_BIND_SERVICE</code></li>
</ul>
</td>
</tr>
</tbody>
</table>
## 정책 초기화
정책 초기화에서의 디커플링(Decoupling) 정책 정의는,
내재되어 있는 시행 메커니즘과 별개로
클러스터 사이의 공통된 이해와 일관된 정책 언어 사용을 가능하게끔 한다.
메커니즘이 발달함에 따라, 아래와 같이 정책별로 정의가 될 것이다.
개별 정책에 대한 시행 방식은 여기서 정의하고 있지 않는다.
[**파드 시큐리티 어드미션 컨트롤러**](/docs/concepts/security/pod-security-admission/)
- {{< example file="security/podsecurity-privileged.yaml" >}}특권 네임스페이스{{< /example >}}
- {{< example file="security/podsecurity-baseline.yaml" >}}기본 네임스페이스{{< /example >}}
- {{< example file="security/podsecurity-restricted.yaml" >}}제한 네임스페이스{{< /example >}}
### 대안
{{% thirdparty-content %}}
쿠버네티스 환경에서 정책을 시행하기 위한 대안이 개발되고 있으며 다음은 몇 가지 예시이다.
- [Kubewarden](https://github.com/kubewarden)
- [Kyverno](https://kyverno.io/policies/pod-security/)
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)
## 파드 OS 필드
쿠버네티스에서는 리눅스 또는 윈도우를 실행하는 노드를 사용할 수 있다.
하나의 클러스터에 두 종류의 노드를 혼합하여 사용할 수 있다.
윈도우 환경 쿠버네티스는 리눅스 기반 워크로드와 비교하였을 때 몇 가지 제한사항 및 차별점이 있다.
구체적으로 말하자면, 대부분의 파드 `securityContext` 필드는
[윈도우 환경에서 효과가 없다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext).
{{< note >}}
v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며, 만일 클러스터 내에 v1.24 이전에 해당하는 노드가 있다면 v1.25 이전 버전의 제한 정책을 적용해야 한다.
{{< /note >}}
### 제한 파드의 시큐리티 스탠다드 변화
쿠버네티스 v1.25에서 나타난 또 다른 중요 변화는, _제한_ 파드 시큐리티가 `pod.spec.os.name` 필드를 사용하도록 업데이트 되었다는 것이다.
특정 OS에 특화된 일부 정책은 OS 이름에 근거하여
다른 OS에 대해서는 완화될 수 있다
#### 특정 OS 정책 제어
`spec.os.name`의 값이 `windows`가 아닐 시에만 다음 제어 항목에 대한 제한 사항이 요구된다.
- 권한 상승
- Seccomp
- Linux 기능
## FAQ
### 왜 특권 프로필과 기본 프로필 사이의 프로필은 없는 것인가?
여기서 정의된 세 가지 프로필은 가장 높은 보안에서(제한 프로필) 가장 낮은 보안까지(특권 프로필)
명백한 선형 관계를 가지며 넓은 범위의 워크로드를 다룬다.
기본 정책을 넘는 요청 권한은 일반적으로 애플리케이션 전용에 속하므로 이러한 틈새시장에 대해서는 표준 프로필을 제공하지 않는다.
이 경우에는 항상 특권 프로필을 사용해야 한다는 주장은 아니지만,
해당 영역의 정책은 케이스 별로 정의되어야 한다는 것이다.
이외 프로필이 분명히 필요하다면 SIG Auth는 향후에 이러한 입장을 재고할 수 있다.
### 시큐리티 컨텍스트와 시큐리티 프로필의 차이점은 무엇인가?
[시큐리티 컨텍스트](/docs/tasks/configure-pod-container/security-context/)는 파드 및 컨테이너를 런타임에 설정한다.
시큐리티 컨텍스트는 파드 매니페스트 내
파드 및 컨테이너 명세의 일부로 정의되고 컨테이너 런타임에 파라미터로 제공한다.
시큐리티 프로필은 컨트롤 플레인 메커니즘으로, 시큐리티 컨텍스트의 상세 설정을 비롯하여
시큐리티 컨텍스트 외부의 다른 관련된 파라미터도 적용한다.
2021년 7월부로, [파드 시큐리티 폴리시](/ko/docs/concepts/security/pod-security-policy/)는
내장된 [파드 시큐리티 어드미션 컨트롤러](/docs/concepts/security/pod-security-admission/)에 의해 대체되어 사용이 중단되었다.
### 샌드박스 파드는 어떠한가?
현재로서는, 파드가 샌드박스 특성을 가지는지 제어할 수 있는 API 표준이 존재하지 않는다.
샌드박스 파드는 샌드박스 런타임(예를 들면, gVisor 혹은 Kata 컨테이너)을 통해 식별할 수 있지만,
샌드박스 런타임이 무엇인지에 대한 표준 정의는 없는 상태이다.
샌드박스 워크로드가 필요로하는 보호물은 다른 워크로드와 다를 수 있다.
예를 들어, 내재된 커널과 분리된 워크로드에서는 제한된 특수 권한의 필요성이 적어진다.
이는 높아진 권한을 요구하는 워크로드가 분리될 수 있도록 허용한다.
추가적으로, 샌드박스 방식에 따라 샌드박스 워크로드에 대한 보호가 달라진다.
이와 같은 경우에는, 하나의 프로필만을 모든 샌드박스 워크로드에 대해 권장할 수 없다.

189
content/ko/docs/concepts/security/rbac-good-practices.md Normal file
View File

@ -0,0 +1,189 @@
---
reviewers:
title: 역할 기반 접근 제어 (RBAC) 모범 사례
description: >
클러스터 운영자를 위한 모범 RBAC 설정 규칙 및 사례
content_type: concept
weight: 60
---
<!-- overview -->
쿠버네티스 {{< glossary_tooltip text="RBAC" term_id="rbac" >}}는
클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만
접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는,
보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해
권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다.
여기서 제공하는 모범 사례는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
와 함께 읽는 것을 권장한다.
<!-- body -->
## 보편적인 모범 사례
### 최소 권한
이상적으로는, 최소의 RBAC 권한만이 사용자 및 서비스 어카운트에 부여되어야 한다.
작업에 명시적으로 필요한 권한만 사용되어야 한다.
각 클러스터마다 경우가 다르겠지만, 여기서 적용해 볼 수 있는 보편적 규칙은 다음과 같다.
- 권한은 가능하면 네임스페이스 레벨에서 부여한다.
클러스터롤바인딩 대신 롤바인딩을 사용하여 특정 네임스페이스 내에서만 사용자에게 권한을 부여한다.
- 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다.
쿠버네티스는 확장성을 지니는 시스템이기 때문에,
와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라
추후에 생성될 오브젝트 타입에 대해서도 권한을 부여하게 된다.
- 운영자는 `cluster-admin` 계정이 필수로 요구되지 않을시에는 사용을 지양한다.
적은 권한을 가진 계정과
[가장 (impersonation) 권한](/docs/reference/access-authn-authz/authentication/#user-impersonation)을
혼합하여 사용하면 클러스터 자원을 실수로 수정하는 일을 방지할 수 있다.
- `system:masters` 그룹에 사용자 추가를 지양한다.
해당 그룹의 멤버는 누구나 모든 RBAC 권한 체크를 우회할 수 있으며 롤바인딩과 클러스터 롤바인딩을
통한 권한 회수가 불가능한 슈퍼유저 (superuser) 권한을 가지게 된다.
추가적으로 클러스터가 권한 웹훅을 사용할 시에는,
그룹의 멤버가 해당 웹훅도 우회할 수 있다. (그룹의 멤버인 사용자가 전송하는 요청은 웹훅에 전달되지 않는다.)
### 특권 토큰 분배 최소화
이상적인 상황에서는, 강력한 권한이 부여된 서비스 어카운트를 파드에게 지정해서는 안된다.
(예를 들어, [권한 에스컬레이션 위험](#privilege-escalation-risks)에 명시된 모든 권한)
워크로드가 강력한 권한을 요구하는 상황에서는 다음과 같은 사례를 고려해 보자.
- 강력한 권한을 가진 파드를 실행하는 노드의 수를 제한한다.
컨테이너 이스케이프의 영향 범위를 최소화하기 위해, 실행되고 있는 모든 데몬셋은 최소의 권한만을 가지도록 한다.
- 강력한 권한을 가진 파드를 신뢰되지 못하거나 외부로 노출된 파드와 함께 실행하는 것을 지양한다.
신뢰되지 못하거나 신뢰성이 적은 파드와 함께 실행되는 것을 방지하기 위해
[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/),
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), 혹은
[파드 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)를 사용해 보는 것도 고려해 보자.
신뢰성이 적은 파드가 **제한된** 파드 시큐리티 스탠다드에 부합하지 않을 시에는 더욱 조심해야 한다.
### 하드닝 (Hardening)
모든 클러스터에서 요구되지 않더라도, 쿠버네티스에서는 기본으로 제공하는 권한이 있다.
기본으로 부여되는 RBAC 권리에 대한 검토를 통해 보안 하드닝을 할 수 있다.
보편적으로는 `system:` 계정에 부여되는 권한을 수정하는 것은 지양한다.
클러스터 권한을 하드닝할 수 있는 방법은 다음과 같다.
- `system:unauthenticated` 그룹의 바인딩은 누구에게나
네트워크 레벨에서 API 서버와 통신할 수 있는 권한을 부여하므로, 바인딩을 검토해 보고 가능하면 제거한다.
- `automountServiceAccountToken: false`를 설정함으로써, 서비스 어카운트 토큰의 자동 마운트 사용을 지양한다.
더 자세한 내용은
[기본 서비스 어카운트 토큰 사용법](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)을 참고한다.
파드에서 위와 같은 설정을 하게 된다면,
서비스 어카운트 설정을 덮어쓰게 되며 서비스 어카운트 토큰을 요구하는 워크로드는 여전히 마운트가 가능하다.
### 주기적 검토
중복된 항목 및 권한 에스컬레이션에 대비하여,
쿠버네티스 RBAC 설정을 주기적으로 검토하는 일은 중요하다.
만일 공격자가 삭제된 사용자와 같은 이름으로 사용자 계정을 생성할 수 있다면,
삭제된 사용자의 모든 권한, 특히 해당 사용자에게 부여되었던 권한까지도
자동으로 상속받을 수 있게 된다.
## 쿠버네티스 RBAC - 권한 에스컬레이션 위험 {#privilege-escalation-risks}
쿠버네티스 RBAC 중, 부여받을 시 사용자 또는 서비스 어카운트가 권한 에스컬레이션을 통해
클러스터 밖의 시스템까지 영향을 미칠 수 있게끔 하는 권한이 몇 가지 존재한다.
해당 섹션은 클러스터 운영자가 실수로 클러스터에 의도되지 않은 접근 권한을
부여하지 않도록 하기 위해 신경 써야 할 부분에 대한 시야를 제공하는 것이 목적이다.
### 시크릿 나열
시크릿에 대해 `get` 권한을 부여하는 행위는 사용자에게 해당 내용에 대한 열람을 허용하는 일이라는 것은 명확히 알려져 있다.
`list` 및 `watch` 권한 또한 사용자가 시크릿의 내용을 열람할 수 있는 권한을 부여한다는 것을 알고 지나가는 것이 중요하다.
예를 들어 리스트 응답이 반환되면 (예를 들어, `kubectl get secrets -A -o yaml`을 통해),
해당 응답에는 모든 시크릿의 내용이 포함되어 있다.
### 워크로드 생성
워크로드(파드 혹은 파드를 관리하는
[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 사용자는
[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)에
기반한 제한 사항이 없을 시에는 해당 노드에 대한 접근 권한을 부여받을 수 있다.
특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며,
더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다.
특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면,
**베이스라인** 혹은 **제한된** 파드 시큐리티 스탠다드를 사용해야 한다.
이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
사용자의 특권을 가진 파드 생성 자격을 제한하기 위해,
현재는 사용이 중지 된 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)
매커니즘도 사용할 수 있다. (주의 - 파드시큐리티폴리시는 1.25 버전 이후로 중지될 예정이다.)
사용자가 네임스페이스 내에서 워크로드를 생성하면, 해당 네임스페이스에 위치한 시크릿에 대한 간접적 접근 권한을 부여 받게 된다.
사용자가 kube-system 또는 유사한 특권을 가진 네임스페이스에서 파드를 생성하게 되면,
RBAC를 통해 직접적으로는 접근 권한을 가지지 못할 시크릿에 대한 권한도 부여받게 된다.
### 퍼시스턴트 볼륨 생성
[파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/#volumes-and-file-systems) 문서에서도 언급이 되었듯이,
퍼시스턴트볼륨 생성 권한은 해당 호스트에 대한 권한 에스컬레이션으로 이어질 수 있다.
퍼시스턴트 스토리지에 대한 권한이 필요할 시에는 신뢰 가능한 관리자를 통해 퍼시스턴트볼륨을 생성하고,
제한된 권한을 가진 사용자는 퍼시스턴트볼륨클레임을 통해 해당 스토리지에 접근하는 것이 바람직하다.
### 노드의 `proxy` 하위 리소스에 대한 접근
노드 오브젝트의 하위 리소스인 프록시에 대한 접근 권한을 가지는 사용자는 Kubelet API에 대한 권한도 가지며,
이는 권한을 가지고 있는 노드에 위치한 모든 파드에서 명령어 실행 권한이 주어짐을 의미한다.
이러한 접근 권한을 통해 감시 로깅 및 어드미션 컨트롤에 대한 우회가 가능해짐으로,
해당 리소스에 대한 권한을 부여할 시에는 주의가 필요하다.
### 에스컬레이트 동사
사용자가 자신이 보유한 권한보다 더 많은 권한을 가진 클러스터롤을 생성하고자 할때, RBAC 시스템이 이를 막는 것이 보편적이다.
이와 관련하여, `escalate` 동사가 예외에 해당한다. [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)에서도 언급이 되었듯이,
해당 권한을 가진 사용자는 권한 에스컬레이션을 할 수 있다.
### 바인드 동사
해당 권한을 사용자에게 부여함으로써 `escalate` 동사와 유사하게
권한 에스컬레이션에 대한 쿠버네티스에 내장된 보호 기능을 우회할 수 있게 되며,
이는 사용자가 부여받지 않은 권한을 가진 롤에 대한 바인딩을 생성할 수 있게끔 한다.
### 가장 (Impersonate) 동사
사용자는 해당 동사를 통해 클러스터 내에서 다른 사용자를 가장하여 권한을 부여받을 수 있게 된다.
가장된 계정을 통해 필요 이상의 권한이 부여되지 않도록
해당 동사 부여시 주의를 기울일 필요가 있다.
### CSR 및 증명서 발급
CSR API를 통해 CSR에 대한 `create` 권한 및 `certificatesigningrequests/approval`에 대한 `update` 권한을 가진 사용자가,
서명자가 `kubernetes.io/kube-apiserver-client`인 새로운 클라이언트 증명서를 생성할 수 있게 되며 이를 통해 사용자는 클러스터를 인증할 수 있게 된다.
해당 클라이언트 증명서는 임의의 이름을 가지게 되며, 이에 중복된 쿠버네티스 시스템 구성 요소도 포함 된다.
이는 권한 에스컬레이션 발생 가능성을 열어두게 된다.
### 토큰 요청
`serviceaccounts/token`에 대해 `create` 권한을 가지는 사용자는
기존의 서비스 어카운트에 토큰을 발급할 수 있는 토큰리퀘스트를 생성할 수 있다.
### 컨트롤 어드미션 웹훅
`validatingwebhookconfigurations` 혹은 `mutatingwebhookconfigurations`에 대한 제어권을 가지는 사용자는
클러스터가 승인한 모든 오브젝트를 열람할 수 있는 웹훅을 제어할 수 있으며,
변화하는 웹훅의 경우에는 승인된 오브젝트를 변화시킬 수도 있다.
## 쿠버네티스 RBAC - 서비스 거부 위험 {#denial-of-service-risks}
### 객체 생성 서비스 거부 {#object-creation-dos}
클러스터 내 오브젝트 생성 권한을 가지는 사용자는
[쿠버네티스가 사용하는 etcd는 OOM 공격에 취약](https://github.com/kubernetes/kubernetes/issues/107325)에서 언급 되었듯이,
서비스 거부 현상을 초래할 정도 규모의 오브젝트를 생성할 수 있다.
다중 테넌트 클러스터에서 신뢰되지 못하거나 신뢰성이 적은 사용자에게
시스템에 대해 제한된 권한이 부여된다면 해당 현상이 나타날 수 있다.
해당 문제의 완화 방안 중 하나로는,
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/#object-count-quota)를 사용하여
생성할 수 있는 오브젝트의 수량을 제한하는 방법이 있다.
## {{% heading "whatsnext" %}}
* RBAC에 대한 추가적인 정보를 얻기 위해서는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/)를 참고한다.

25
content/ko/docs/concepts/security/windows-security.md
View File

@ -17,12 +17,13 @@ weight: 40
## 노드의 시크릿 데이터 보호
윈도우에서, 시크릿에 있던 데이터는 노드의 로컬 스토리지에
윈도우에서는 시크릿 데이터가 노드의 로컬 스토리지에
평문으로 기록된다(리눅스는 tmpfs 또는 인메모리 파일시스템에 기록).
클러스터 운영자로서, 다음 2 가지의 추가 사항을 고려해야 한다.
1. 파일 ACL을 사용하여 시크릿의 파일 위치를 보호한다.
1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여 볼륨 수준의 암호화를 적용한다.
1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여
볼륨 수준의 암호화를 적용한다.
## 컨테이너 사용자
@ -31,25 +32,31 @@ weight: 40
해당 컨테이너 프로세스를 실행할 사용자를 지정할 수 있다.
이는 [RunAsUser](/ko/docs/concepts/security/pod-security-policy/#사용자-및-그룹)와 대략적으로 동등하다.
윈도우 컨테이너는 ContainerUser와 ContainerAdministrator의 2 개의 기본 사용자 계정을 제공한다.
윈도우 컨테이너는 ContainerUser와 ContainerAdministrator라는 기본 사용자 계정을 2개 제공한다.
이 두 사용자 계정이 어떻게 다른지는 마이크로소프트의 _안전한 윈도우 컨테이너_ 문서 내의
[언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)를 참고한다.
[언제 ContainerAdmin 및 ContainerUser 사용자 계정을 사용해야 하는가](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)를
참고한다.
컨테이너 빌드 과정에서 컨테이너 이미지에 로컬 사용자를 추가할 수 있다.
{{< note >}}
* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 기반 이미지는 기본적으로 `ContainerUser`로 실행된다
* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 기반 이미지는 기본적으로 `ContainerAdministrator`로 실행된다
* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 기반 이미지는
기본적으로 `ContainerUser`로 실행된다
* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 기반 이미지는
기본적으로 `ContainerAdministrator`로 실행된다
{{< /note >}}
[그룹 관리 서비스 어카운트](/ko/docs/tasks/configure-pod-container/configure-gmsa/)를 활용하여 윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.
[그룹 관리 서비스 어카운트](/ko/docs/tasks/configure-pod-container/configure-gmsa/)를 활용하여
윈도우 컨테이너를 Active Directory 사용자로 실행할 수도 있다.
## 파드-수준 보안 격리
리눅스 특유의 파드 보안 컨텍스트 메커니즘(예: SELinux, AppArmor, Seccomp,
또는 커스텀 POSIX 기능)은 윈도우 노드에서 지원되지 않는다.
특권을 가진(Privileged) 컨테이너는 윈도우에서 [지원되지 않는다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext).
대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해 [HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 사용할 수 있다.
특권을 가진(Privileged) 컨테이너는
윈도우에서 [지원되지 않는다](/ko/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext).
대신, 리눅스에서 권한 있는 컨테이너가 할 수 있는 작업 중 많은 부분을 윈도우에서 수행하기 위해
[HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 사용할 수 있다.

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

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

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

@ -174,7 +174,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
kind: Service
metadata:
labels:
app: MyApp
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: 10.0.197.123
@ -188,7 +188,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
protocol: TCP
targetPort: 80
selector:
app: MyApp
app.kubernetes.io/name: MyApp
type: ClusterIP
status:
loadBalancer: {}
@ -214,7 +214,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
kind: Service
metadata:
labels:
app: MyApp
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: None
@ -228,7 +228,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
protocol: TCP
targetPort: 80
selector:
app: MyApp
app.kubernetes.io/name: MyApp
```
#### 단일 스택과 이중 스택 간 서비스 전환
@ -305,7 +305,7 @@ IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주
{{< /note >}}
윈도우의 다른 네트워크 모델에 대한 내용은
[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다.
[윈도우에서의 네트워킹](/ko/docs/concepts/services-networking/windows-networking/#네트워크-모드)을 살펴본다.
## {{% heading "whatsnext" %}}

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

@ -1,6 +1,6 @@
---
# reviewers:
# - freehan
title: 엔드포인트슬라이스
content_type: concept
weight: 45

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

@ -1,6 +1,6 @@
---
title: 인그레스 컨트롤러
reviewers:
# reviewers:
content_type: concept
weight: 40
---

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

@ -1,6 +1,6 @@
---
## reviewers:
## - bprashanth
# reviewers:
# - bprashanth
title: 인그레스(Ingress)
content_type: concept
weight: 40

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

@ -1,8 +1,8 @@
---
## reviewers:
## - thockin
## - caseydavenport
## - danwinship
# reviewers:
# - thockin
# - caseydavenport
# - danwinship
title: 네트워크 정책
content_type: concept
weight: 50

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

@ -1,7 +1,7 @@
---
# reviewers:
# - johnbelamaric
# - imroc
title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅
content_type: concept
weight: 10

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

@ -1,6 +1,6 @@
---
## reviewers:
## - maplain
# reviewers:
# - maplain
title: 서비스 내부 트래픽 정책
content_type: concept
weight: 45
@ -43,7 +43,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -63,5 +63,5 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

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

@ -1,6 +1,6 @@
---
## reviewers:
## - bprashanth
# reviewers:
# - bprashanth
title: 서비스
feature:
title: 서비스 디스커버리와 로드 밸런싱
@ -75,7 +75,7 @@ _서비스_ 로 들어가보자.
[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
`app.kubernetes.io/name=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
```yaml
apiVersion: v1
@ -84,7 +84,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -92,7 +92,7 @@ spec:
```
이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고,
`app=MyApp` 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
`app.kubernetes.io/name=MyApp` 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함)
를 할당한다.
@ -126,7 +126,7 @@ spec:
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
@ -144,9 +144,9 @@ spec:
이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고,
단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고,
백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
서비스의 기본 프로토콜은 TCP이다. 다른
@ -159,7 +159,7 @@ spec:
### 셀렉터가 없는 서비스
서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만,
셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
@ -204,8 +204,8 @@ subsets:
엔드포인트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
서비스를 위한 객체인 [엔드포인트](/ko/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
를 만들 때, 새로운 객체의 이름을
서비스를 위한 객체인 [엔드포인트](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)를 만들 때,
새로운 객체의 이름을
그것의 서비스 이름과 같게 설정해야 한다.
{{< note >}}
@ -299,9 +299,14 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
### 구성
kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한
컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다.
예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우,
표준 커널 kube-proxy 구현체는 작동하지 않을 것이다.
마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는,
윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
@ -418,7 +423,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
@ -492,7 +497,11 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
### 환경 변수
파드가 노드에서 실행될 때, 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) 참조)도 지원한다.
`{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`는,
@ -604,8 +613,10 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
CoreDNS 버전 1.7 이상이 필요하다.
{{< /note >}}
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다.
인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다.
동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에
라우팅 규칙을 단일 리소스로 통합할 수 있다.
### NodePort 유형 {#type-nodeport}
@ -620,9 +631,14 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 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에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면,
kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다.
`--nodeport-addresses`의 기본 값은 비어있는 목록이다.
이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다.
(이는 이전 쿠버네티스 릴리스와도 호환된다).
특정 포트 번호를 원한다면, `nodePort` 필드에 값을 지정할 수
있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이
@ -650,7 +666,7 @@ metadata:
spec:
type: NodePort
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
# 기본적으로 그리고 편의상 `targetPort` 는 `port` 필드와 동일한 값으로 설정된다.
- port: 80
@ -676,7 +692,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -689,7 +705,8 @@ status:
- ip: 192.0.2.127
```
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다.
클라우드 공급자는 로드 밸런싱 방식을 결정한다.
일부 클라우드 공급자는 `loadBalancerIP`를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
사용자 지정 `loadBalancerIP`로 생성된다. `loadBalancerIP` 필드가 지정되지 않으면,
@ -704,7 +721,11 @@ status:
클러스터에서 자동으로 생성된 다른 리소스와 동일한 리소스 그룹에 있어야 한다.
예를 들면, `MC_myResourceGroup_myAKSCluster_eastus`이다.
할당된 IP 주소를 loadBalancerIP로 지정한다. 클라우드 공급자 구성 파일에서 securityGroupName을 업데이트했는지 확인한다. `CreatingLoadBalancerFailed` 권한 문제 해결에 대한 자세한 내용은 [Azure Kubernetes Service (AKS) 로드 밸런서에서 고정 IP 주소 사용](https://docs.microsoft.com/en-us/azure/aks/static-ip) 또는 [고급 네트워킹 AKS 클러스터에서 CreateLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)를 참고한다.
할당된 IP 주소를 loadBalancerIP로 지정한다. 클라우드 공급자 구성 파일에서
`securityGroupName`을 업데이트했는지 확인한다.
`CreatingLoadBalancerFailed` 권한 문제 해결에 대한 자세한 내용은
[Azure Kubernetes Service (AKS) 로드 밸런서에서 고정 IP 주소 사용](https://docs.microsoft.com/en-us/azure/aks/static-ip)
또는 [고급 네트워킹 AKS 클러스터에서 CreateLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)를 참고한다.
{{< /note >}}
@ -743,7 +764,7 @@ status:
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
@ -760,7 +781,8 @@ status:
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
라우팅해야 하는 경우가 있다.
수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.
수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는
두 개의 서비스가 필요하다.
내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
다음의 어노테이션 중 하나를 서비스에 추가한다.
@ -925,7 +947,9 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우,
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다.
쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
쿠버네티스 v1.9부터는 서비스에 대한
HTTPS 또는 SSL 리스너와 함께
[사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
```bash
@ -981,14 +1005,17 @@ Amazon S3 버킷을 생성한 논리적 계층을 지정한다.
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
# 로드 밸런서의 접근 로그 활성화 여부를 명시.
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
# 접근 로그를 게시하는 간격을 분 단위로 제어. 5분 또는 60분의 간격을 지정.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
# 로드 밸런서 접근 로그가 저장되는 Amazon S3 버킷의 이름 명시.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
# Amazon S3 버킷을 생성한 논리적 계층을 지정. 예: `my-bucket-prefix/prod`
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
```
#### AWS의 연결 드레이닝(Draining)
@ -997,7 +1024,8 @@ Classic ELB의 연결 드레이닝은
`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 어노테이션을
`"true"`값으로 설정하여 관리할 수 ​​있다. `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` 어노테이션을
사용하여 인스턴스를 해제하기 전에,
기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.
기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로
설정할 수도 있다.
```yaml
metadata:
@ -1015,50 +1043,56 @@ Classic ELB의 연결 드레이닝은
metadata:
name: my-service
annotations:
# 로드 밸런서가 연결을 닫기 전에, 유휴 상태(연결을 통해 전송 된
# 데이터가 없음)의 연결을 허용하는 초단위 시간
service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
# 로드 밸런서가 연결을 닫기 전에, 유휴 상태(연결을 통해 전송 된 데이터가 없음)의 연결을 허용하는 초단위 시간
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
# 로드 밸런서에 교차-영역(cross-zone) 로드 밸런싱을 사용할 지 여부를 지정
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"
# 쉼표로 구분된 key-value 목록은 ELB에
# 추가 태그로 기록됨
service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"
service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
# 백엔드가 정상인 것으로 간주되는데 필요한 연속적인
# 헬스 체크 성공 횟수이다. 기본값은 2이며, 2와 10 사이여야 한다.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# 백엔드가 비정상인 것으로 간주되는데 필요한
# 헬스 체크 실패 횟수이다. 기본값은 6이며, 2와 10 사이여야 한다.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# 개별 인스턴스의 상태 점검 사이의
# 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)
# 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
# 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록.
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리,
# 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,
# '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다.
# 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다.
# 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다.
# 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이
# 워커 노드로 향하도록 하는 규칙으로 사용된다.
# 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이
# 워커 노드 보안 그룹에 추가된다.
# 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다.
# 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다.
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
# 생성된 ELB에 추가할 추가 보안 그룹 목록
# 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여
# 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.
# 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로,
# 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여
# 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다.
# 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
# 로드 밸런서의 대상 노드를 선택하는 데
# 사용되는 키-값 쌍의 쉼표로 구분된 목록
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
```
#### AWS의 네트워크 로드 밸런서 지원 {#aws-nlb-support}
@ -1075,7 +1109,8 @@ AWS에서 네트워크 로드 밸런서를 사용하려면, `nlb` 값이 설정
```
{{< note >}}
NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 [AWS 문서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한
[AWS 문서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
를 참고한다.
{{< /note >}}
@ -1182,7 +1217,8 @@ spec:
```
{{< note >}}
ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다.
IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다.
{{< /note >}}
@ -1196,9 +1232,13 @@ ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌
서비스의 `유형(type)`을 변경할 수 있다.
{{< warning >}}
HTTP 및 HTTPS를 포함한, 몇몇 일반적인 프로토콜에 ExternalName을 사용하는 것은 문제가 있을 수 있다. ExternalName을 사용하는 경우, 클러스터 내부의 클라이언트가 사용하는 호스트 이름(hostname)이 ExternalName이 참조하는 이름과 다르다.
HTTP 및 HTTPS를 포함한, 몇몇 일반적인 프로토콜에 ExternalName을 사용하는 것은 문제가 있을 수 있다.
ExternalName을 사용하는 경우, 클러스터 내부의 클라이언트가 사용하는 호스트 이름(hostname)이
ExternalName이 참조하는 이름과 다르다.
호스트 이름을 사용하는 프로토콜의 경우, 이러한 차이로 인해 오류가 발생하거나 예기치 않은 응답이 발생할 수 있다. HTTP 요청에는 오리진(origin) 서버가 인식하지 못하는 `Host :` 헤더가 있다. TLS 서버는 클라이언트가 연결된 호스트 이름과 일치하는 인증서를 제공할 수 없다.
호스트 이름을 사용하는 프로토콜의 경우, 이러한 차이로 인해 오류가 발생하거나 예기치 않은 응답이 발생할 수 있다.
HTTP 요청에는 오리진(origin) 서버가 인식하지 못하는 `Host :` 헤더가 있다.
TLS 서버는 클라이언트가 연결된 호스트 이름과 일치하는 인증서를 제공할 수 없다.
{{< /warning >}}
{{< note >}}
@ -1220,7 +1260,7 @@ HTTP 및 HTTPS를 포함한, 몇몇 일반적인 프로토콜에 ExternalName을
apiVersion: v1
kind: Service
metadata:
name: my-service
app.kubernetes.io/name: MyApp
spec:
selector:
app: MyApp
@ -1357,12 +1397,15 @@ IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정
#### IPVS
iptables 작업은 대규모 클러스터 (예: 10,000 서비스)에서 크게 느려진다.
IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다. 따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다. 한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘 (least conns, locality, weighted, persistence)을 가진다.
IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다.
따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다.
한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘
(least conns, locality, weighted, persistence)을 가진다.
## API 오브젝트
서비스는 쿠버네티스 REST API의 최상위 리소스이다. API 오브젝트에 대한
자세한 내용은 다음을 참고한다. [서비스 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
서비스는 쿠버네티스 REST API의 최상위 리소스이다. [서비스 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)에 대한
자세한 내용을 참고할 수 있다.
## 지원되는 프로토콜 {#protocol-support}
@ -1388,7 +1431,8 @@ type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed}
{{< warning >}}
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해
멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
{{< /warning >}}

4
content/ko/docs/concepts/services-networking/topology-aware-hints.md
View File

@ -1,6 +1,6 @@
---
# reviewers:
# - robscott
title: 토폴로지 인지 힌트
content_type: concept
weight: 45

7
content/ko/docs/concepts/storage/dynamic-provisioning.md
View File

@ -1,4 +1,9 @@
---
# reviewers:
# - saad-ali
# - jsafrane
# - thockin
# - msau42
title: 동적 볼륨 프로비저닝
content_type: concept
weight: 40
@ -110,7 +115,7 @@ spec:
- API 서버에서 [`DefaultStorageClass` 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를
사용하도록 설정한다.
관리자는 `storageclass.kubernetes.io/is-default-class` 어노테이션을
관리자는 `storageclass.kubernetes.io/is-default-class` [어노테이션](/ko/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class)을
추가해서 특정 `StorageClass` 를 기본으로 표시할 수 있다.
기본 `StorageClass` 가 클러스터에 존재하고 사용자가
`storageClassName` 를 지정하지 않은 `PersistentVolumeClaim` 을

26
content/ko/docs/concepts/storage/ephemeral-volumes.md
View File

@ -1,10 +1,10 @@
---
## reviewers:
## - jsafrane
## - saad-ali
## - msau42
## - xing-yang
## - pohly
# reviewers:
# - jsafrane
# - saad-ali
# - msau42
# - xing-yang
# - pohly
title: 임시 볼륨
content_type: concept
weight: 30
@ -136,8 +136,11 @@ CSI 임시 볼륨은 사용자로 하여금 `volumeAttributes`를
클러스터 관리자가 이처럼 파드 스펙 내장 임시 볼륨 사용이 가능한 CSI 드라이버를 제한하려면
다음을 수행할 수 있다.
- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여, 해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다.
- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 드라이버를 활용하는 방법을 제한한다.
- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여,
해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다.
- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여
드라이버를 활용하는 방법을 제한한다.
### 일반 임시 볼륨 {#generic-ephemeral-volumes}
@ -207,7 +210,7 @@ spec:
즉각적인 바인딩을 사용하는 경우,
스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다.
[리소스 소유권](/docs/concepts/workloads/controllers/garbage-collection/#owners-dependents) 관점에서,
[리소스 소유권](/ko/docs/concepts/architecture/garbage-collection/#owners-dependents) 관점에서,
일반 임시 스토리지를 갖는 파드는
해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다.
파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데,
@ -250,8 +253,9 @@ PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할
GenericEphemeralVolume 기능을 활성화하면
사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며,
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 클러스터 관리자는 이를 명심해야 한다.
이것이 보안 모델에 부합하지 않는다면, [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다.
클러스터 관리자는 이를 명심해야 한다. 이것이 보안 모델에 부합하지 않는다면,
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여
일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부해야 한다.
일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로,

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

@ -1,10 +1,10 @@
---
## reviewers:
## - jsafrane
## - saad-ali
## - thockin
## - msau42
## - xing-yang
# reviewers:
# - jsafrane
# - saad-ali
# - thockin
# - msau42
# - xing-yang
title: 퍼시스턴트 볼륨
feature:
title: 스토리지 오케스트레이션
@ -558,10 +558,10 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
| AzureFile | &#x2713; | &#x2713; | &#x2713; | - |
| AzureDisk | &#x2713; | - | - | - |
| CephFS | &#x2713; | &#x2713; | &#x2713; | - |
| Cinder | &#x2713; | - | - | - |
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
| Cinder | &#x2713; | - | ([다중 부착(multi-attached)이 가능한 볼륨이라면](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes)) | - |
| CSI | 드라이버에 의존 | 드라이버에 의존 | 드라이버에 의존 | 드라이버에 의존 |
| FC | &#x2713; | &#x2713; | - | - |
| FlexVolume | &#x2713; | &#x2713; | depends on the driver | - |
| FlexVolume | &#x2713; | &#x2713; | 드라이버에 의존 | - |
| Flocker | &#x2713; | - | - | - |
| GCEPersistentDisk | &#x2713; | &#x2713; | - | - |
| Glusterfs | &#x2713; | &#x2713; | &#x2713; | - |
@ -570,7 +570,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
| Quobyte | &#x2713; | &#x2713; | &#x2713; | - |
| NFS | &#x2713; | &#x2713; | &#x2713; | - |
| RBD | &#x2713; | &#x2713; | - | - |
| VsphereVolume | &#x2713; | - | - (works when Pods are collocated) | - |
| VsphereVolume | &#x2713; | - | - (파드를 배치할(collocated) 때 동작한다) | - |
| PortworxVolume | &#x2713; | - | &#x2713; | - | - |
| StorageOS | &#x2713; | - | - | - |
@ -1002,12 +1002,12 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
퍼시스턴트볼륨 오브젝트를 구성에 포함하지 않는다.
- 템플릿을 인스턴스화 할 때 스토리지 클래스 이름을 제공하는 옵션을
사용자에게 제공한다.
- 사용자가 스토리지 클래스 이름을 제공하는 경우 해당 값을
`permanentVolumeClaim.storageClassName` 필드에 입력한다.
- 사용자가 스토리지 클래스 이름을 제공하는 경우 해당 값을
`permanentVolumeClaim.storageClassName` 필드에 입력한다.
클러스터에서 관리자가 스토리지클래스를 활성화한 경우
PVC가 올바른 스토리지 클래스와 일치하게 된다.
- 사용자가 스토리지 클래스 이름을 제공하지 않으면
`permanentVolumeClaim.storageClassName` 필드를 nil로 남겨둔다.
- 사용자가 스토리지 클래스 이름을 제공하지 않으면
`permanentVolumeClaim.storageClassName` 필드를 nil로 남겨둔다.
그러면 클러스터에 기본 스토리지클래스가 있는 사용자에 대해 PV가 자동으로 프로비저닝된다.
많은 클러스터 환경에 기본 스토리지클래스가 설치되어 있거나 관리자가
고유한 기본 스토리지클래스를 생성할 수 있다.

127
content/ko/docs/concepts/storage/projected-volumes.md Normal file
View File

@ -0,0 +1,127 @@
---
# reviewers:
# - marosset
# - jsturtevant
# - zshihang
title: 프로젝티드 볼륨
content_type: concept
weight: 21 # just after persistent volumes
---
<!-- overview -->
이 페이지에서는 쿠버네티스의 _프로젝티드 볼륨(projected volume)_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
<!-- body -->
## 들어가며
`프로젝티드 볼륨`은 여러 기존 볼륨 소스(sources)를 동일한 디렉토리에 매핑한다.
현재, 아래와 같은 볼륨 유형 소스를 프로젝트(project)할 수 있다.
* [`시크릿(secret)`](/ko/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/ko/docs/concepts/storage/volumes/#downwardapi)
* [`컨피그맵(configMap)`](/ko/docs/concepts/storage/volumes/#configmap)
* [`서비스어카운트토큰(serviceAccountToken)`](#serviceaccounttoken)
모든 소스는 파드와 같은 네임스페이스에 있어야 한다.
자세한 내용은 [올인원(all-in-one) 볼륨](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) 문서를 참고한다.
### 시크릿, downwardAPI, 컨피그맵 구성 예시 {#example-configuration-secret-downwardapi-configmap}
{{< codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" >}}
### 기본 권한이 아닌 모드 설정의 시크릿 구성 예시 {#example-configuration-secrets-nondefault-permission-mode}
{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
각 프로젝티드 볼륨 소스는 `sources` 아래의 스펙에 나열된다.
파라미터는 두 가지 예외를 제외하고 동일하다.
* 시크릿의 경우 컨피그맵 명명법과 동일하도록
`secretName` 필드가 `name`으로 변경되었다.
* `defaultMode`의 경우 볼륨 소스별 각각 명시할 수 없고
프로젝티드 수준에서만 명시할 수 있다. 그러나 위의 그림처럼 각 개별 프로젝션에 대해
`mode`를 명시적으로 지정할 수 있다.
## 서비스어카운트토큰 프로젝티드 볼륨 {#serviceaccounttoken}
`TokenRequestProjection` 기능이 활성화 된 경우
파드의 지정된 경로에 [서비스어카운트토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)을
주입할 수 있다.
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
위 예시에는 파드에 주입된 서비스어카운트토큰이 포함된 프로젝티드 볼륨이 있다.
이 파드의 컨테이너는 서비스어카운트토큰을 사용하여 쿠버네티스 API 서버에 접근하고,
파드의 [서비스어카운트](/docs/tasks/configure-pod-container/configure-service-account/)로 인증할 수 있다.
`audience` 필드는 토큰의 의도된 대상을 포함한다.
토큰 수신자는 토큰의 대상으로 지정된 식별자로 자신을 식별해야 하며,
그렇지 않으면 토큰을 거부해야 한다.
이 필드는 선택 사항으로, API 서버의 식별자로 기본 설정된다.
`expirationSeconds`는 서비스어카운트토큰의 예상 유효 기간이다.
기본값은 1시간이며 최소 10분 (600초) 이상이어야 한다.
관리자는 API 서버 옵션 `--service-account-max-token-expiration`으로
값을 지정하여 최대값을 제한할 수 있다.
`path` 필드는 프로젝티드 볼륨의 마운트 지점에 대한 상대 경로를 지정한다.
{{< note >}}
[`하위 경로`](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 프로젝티드 볼륨 소스를 사용하는 컨테이너는
해당 볼륨 소스에 대한 업데이트를 수신하지 않는다.
{{< /note >}}
## 시큐리티컨텍스트(SecurityContext) 상호작용
프로젝티드 서비스 어카운트 볼륨 내에서의 파일 퍼미션 처리에 대한 개선 [제안](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal)을 통해, 프로젝티드 파일의 소유자 및 퍼미션이 올바르게 설정되도록 변경되었다.
### 리눅스
프로젝티드 볼륨과 파드
[`보안 컨텍스트`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)에
`RunAsUser`가 설정된 리눅스 파드에서는
프로젝티드파일이 컨테이너 사용자 소유권을 포함한 올바른 소유권 집합을 가진다.
### 윈도우
윈도우 파드에서 프로젝티드 볼륨과 파드 `SecurityContext`에 `RunAsUsername`이 설정된 경우,
윈도우에서 사용자 계정을 관리하는 방법으로 인하여 소유권이 적용되지 않는다.
윈도우는 보안 계정 관리자 (Security Account Manager)라는 데이터베이스 파일에
로컬 사용자 및 그룹 계정을 저장하고 관리한다.
컨테이너가 실행되는 동안 각 컨테이너는
호스트가 볼 수 없는 SAM 데이터베이스의 자체 인스턴스를 유지한다.
윈도우 컨테이너는 OS의 사용자 모드 부분을 호스트와 분리하여 실행하도록 설계되어 가상 SAM 데이터베이스를 유지 관리한다.
따라서 호스트에서 실행 중인 kubelet은 가상화된 컨테이너 계정에 대한
호스트 파일 소유권을 동적으로 구성할 수 없다.
호스트 머신의 파일을 컨테이너와 공유하려는 경우
`C:\` 외부에 있는 자체 볼륨 마운트에 배치하는 것을
권장한다.
기본적으로, 프로젝티드 파일은 예제의 프로젝티드 볼륨 파일처럼
아래와 같은 소유권을 가진다.
```powershell
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner : BUILTIN\Administrators
Group : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Administrators Allow FullControl
BUILTIN\Users Allow ReadAndExecute, Synchronize
Audit :
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
```
`ContainerAdministrator`와 같은
모든 관리자인 사용자는 읽기, 쓰기 그리고 실행 권한을 갖게 되지만
관리자가 아닌 사용자는 읽기 및 실행 권한을 갖게 된다는 것을 의미한다.
{{< note >}}
일반적으로 호스트에게 컨테이너 액세스를 승인하는 것은
잠재적인 보안 악용에 대한 문을 열 수 있기 때문에 권장되지 않는다.
윈도우 파드에서 `SecurityContext`를 `RunAsUser`로 생성하면,
파드는 영원히 `ContainerCreating` 상태에 머물게 된다.
따라서 리눅스 전용 `RunAsUser` 옵션은 윈도우 파드와 함께 사용하지 않는 것이 좋다.
{{< /note >}}

12
content/ko/docs/concepts/storage/storage-capacity.md
View File

@ -1,10 +1,10 @@
---
# reviewers:
# - jsafrane
# - saad-ali
# - msau42
# - xing-yang
# - pohly
title: 스토리지 용량
content_type: concept
weight: 70

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

@ -1,9 +1,9 @@
---
## reviewers:
## - jsafrane
## - saad-ali
## - thockin
## - msau42
# reviewers:
# - jsafrane
# - saad-ali
# - thockin
# - msau42
title: 스토리지 클래스
content_type: concept
weight: 30

5
content/ko/docs/concepts/storage/storage-limits.md
View File

@ -1,4 +1,9 @@
---
# reviewers:
# - jsafrane
# - saad-ali
# - thockin
# - msau42
title: 노드 별 볼륨 한도
content_type: concept
---

10
content/ko/docs/concepts/storage/volume-health-monitoring.md
View File

@ -1,9 +1,9 @@
---
# reviewers:
# - jsafrane
# - saad-ali
# - msau42
# - xing-yang
title: 볼륨 헬스 모니터링
content_type: concept
---

10
content/ko/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -1,9 +1,9 @@
---
# reviewers:
# - jsafrane
# - saad-ali
# - thockin
# - msau42
title: CSI 볼륨 복제하기
content_type: concept
weight: 60

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

@ -1,11 +1,11 @@
---
# reviewers:
# - saad-ali
# - thockin
# - msau42
# - jingxu97
# - xing-yang
# - yuxiangqian
title: 볼륨 스냅샷 클래스
content_type: concept
weight: 41 # just after volume snapshots

14
content/ko/docs/concepts/storage/volume-snapshots.md
View File

@ -1,11 +1,11 @@
---
# reviewers:
# - saad-ali
# - thockin
# - msau42
# - jingxu97
# - xing-yang
# - yuxiangqian
title: 볼륨 스냅샷
content_type: concept
weight: 40

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

@ -1,9 +1,9 @@
---
## reviewers:
## - jsafrane
## - saad-ali
## - thockin
## - msau42
# reviewers:
# - jsafrane
# - saad-ali
# - thockin
# - msau42
title: 볼륨
content_type: concept
weight: 10
@ -837,7 +837,7 @@ spec:
### projected
`Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다.
더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다.
더 자세한 사항은 [projected volumes](/ko/docs/concepts/storage/projected-volumes/)를 참고한다.
### quobyte (사용 중단됨) {#quobyte}

2
content/ko/docs/concepts/windows/intro.md
View File

@ -132,7 +132,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨
* 크론잡(CronJob)
* 레플리케이션컨트롤러(ReplicationController)
* {{< glossary_tooltip text="서비스" term_id="service" >}}
[로드 밸런싱과 서비스](#load-balancing-and-services)에서 상세 사항을 확인한다.
[로드 밸런싱과 서비스](/ko/docs/concepts/services-networking/windows-networking/#load-balancing-and-services)에서 상세 사항을 확인한다.
파드, 워크로드 리소스 및 서비스는
쿠버네티스에서 윈도우 워크로드를 관리하는 데 중요한 요소이다.

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

@ -1,8 +1,8 @@
---
# reviewers:
# - erictune
# - soltysh
# - janetkuo
title: 크론잡
content_type: concept
weight: 80

12
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -1,10 +1,10 @@
---
# reviewers:
# - enisoc
# - erictune
# - foxish
# - janetkuo
# - kow3ns
title: 데몬셋
content_type: concept
weight: 40

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

@ -1,6 +1,6 @@
---
# reviewers:
# - janetkuo
title: 디플로이먼트
feature:
title: 자동화된 롤아웃과 롤백

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

@ -71,7 +71,7 @@ Pod Template:
job-name=pi
Containers:
pi:
Image: perl
Image: perl:5.34.0
Port: <none>
Host Port: <none>
Command:
@ -125,7 +125,7 @@ spec:
- -Mbignum=bpi
- -wle
- print bpi(2000)
image: perl
image: perl:5.34.0
imagePullPolicy: Always
name: pi
resources: {}
@ -268,7 +268,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수
있지만, 그 중 하나만 완료 횟수에 포함된다.
@ -356,7 +356,7 @@ spec:
spec:
containers:
- name: pi
image: perl
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
@ -402,7 +402,7 @@ spec:
spec:
containers:
- name: pi
image: perl
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
@ -486,7 +486,7 @@ spec:
[작업 항목 당 파드가 있는 큐]: /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/
[정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/
[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
## 고급 사용법
@ -510,8 +510,7 @@ spec:
현재 시간으로 재설정된다. 즉, 잡이 일시 중지 및 재개되면 `.spec.activeDeadlineSeconds`
타이머가 중지되고 재설정된다.
잡을 일시 중지하면 모든 활성 파드가 삭제된다. 잡이
일시 중지되면, SIGTERM 시그널로 [파드가 종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
잡을 일시 중지하면, `Completed` 상태가 아닌 모든 실행중인 파드가 SIGTERM 시그널로 [종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
파드의 정상 종료 기간이 적용되며 사용자의 파드는 이 기간 동안에
이 시그널을 처리해야 한다. 나중에 진행 상황을 저장하거나
변경 사항을 취소하는 작업이 포함될 수 있다. 이 방법으로 종료된 파드는
@ -537,6 +536,20 @@ spec:
...
```
명령 줄에서 잡을 패치하여 잡 일시 중지를 전환할 수 있다.
활성화된 잡 일시 중지
```shell
kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":true}}'
```
일시 중지된 잡 재개
```shell
kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":false}}'
```
잡의 상태를 사용하여 잡이 일시 중지되었는지 또는 과거에 일시 중지되었는지
확인할 수 있다.
@ -760,7 +773,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
* [작업 대기열을 사용한 거친 병렬 처리](/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/)(베타) 사용
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
* 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.

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

@ -1,5 +1,5 @@
---
#reviewers:
# reviewers:
#- Kashomon
#- bprashanth
#- madhusudancs
@ -13,9 +13,6 @@ weight: 20
레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.
이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
<!-- body -->
## 레플리카셋의 작동 방식
@ -31,9 +28,9 @@ weight: 20
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나
OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
가지게 될 것이다.
레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에
OwnerReference가 없거나, OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고
레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를 가지게 될 것이다.
## 레플리카셋을 사용하는 시기
@ -253,7 +250,9 @@ matchLabels:
그렇지 않으면 API에 의해 거부된다.
{{< note >}}
2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다.
2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른
`.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은
다른 레플리카셋이 생성한 파드를 무시한다.
{{< /note >}}
### 레플리카
@ -267,11 +266,14 @@ matchLabels:
### 레플리카셋과 해당 파드 삭제
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/architecture/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`로 설정해야 한다. 예시:
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
설정해야 한다.
예시:
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@ -281,9 +283,12 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
### 레플리카셋만 삭제하기
레플리카셋을 `--cascade=orphan` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에
`--cascade=orphan` 옵션을 사용하여
연관 파드에 영향을 주지 않고 레플리카셋을 삭제할 수 있다.
REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다.
예시:
```shell
kubectl proxy --port=8080
curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@ -294,7 +299,8 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
### 레플리카셋에서 파드 격리
@ -310,17 +316,19 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
스케일 다운할 때, 레플리카셋 컨트롤러는 스케일 다운할 파드의
우선순위를 정하기 위해 다음의 기준으로 가용 파드를 정렬하여 삭제할 파드를 결정한다.
1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다.
2. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는
1. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는
파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다.
3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가
1. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
1. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가
이전에 생성된 파드보다 먼저 스케일 다운된다.
(`LogarithmicScaleDown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다)
모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
### 파드 삭제 비용
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
@ -344,6 +352,7 @@ apiserver에서 많은 양의 파드 업데이트를 동반하기 때문이다.
{{< /note >}}
#### 사용 예시
한 애플리케이션 내의 여러 파드는 각각 사용률이 다를 수 있다. 스케일 다운 시,
애플리케이션은 사용률이 낮은 파드를 먼저 삭제하고 싶을 수 있다. 파드를 자주
업데이트하는 것을 피하기 위해, 애플리케이션은 `controller.kubernetes.io/pod-deletion-cost` 값을
@ -387,12 +396,17 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
### 기본 파드
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 Kubelet과 같은 에이전트에게 위임한다.
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는
노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든
종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도
레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면,
레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다.
레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 Kubelet과 같은 에이전트에게 위임한다.
### 잡
스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다
(즉, 배치 잡).
스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신
[`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다 (즉, 배치 잡).
### 데몬셋
@ -402,12 +416,12 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다.
### 레플리케이션 컨트롤러
레플리카셋은 [_레플리케이션 컨트롤러_](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
레플리카셋은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
@ -419,3 +433,4 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

6
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -1,7 +1,7 @@
---
# reviewers:
# - bprashanth
# - janetkuo
title: 레플리케이션 컨트롤러
feature:
title: 자가 치유

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

@ -1,11 +1,11 @@
---
# reviewers:
# - enisoc
# - erictune
# - foxish
# - janetkuo
# - kow3ns
# - smarterclayton
title: 스테이트풀셋
content_type: concept
weight: 30
@ -39,10 +39,18 @@ weight: 30
## 제한사항
* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
* 파드에 지정된 스토리지는 관리자에 의해
[퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)
를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*.
이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한
데이터의 안전을 보장하기 위함이다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
가 필요하다. 사용자가 이 서비스를 생성할 책임이
있다.
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지
않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면,
삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
* [롤링 업데이트](#롤링-업데이트)와 기본
[파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이
@ -108,18 +116,24 @@ spec:
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한
[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서
안정적인 스토리지를 제공한다.
스테이트풀셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
### 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
스테이트풀셋의 `.spec.selector` 필드는
`.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면
스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
### 볼륨 클레임 템플릿
`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를 제공할 수 있다.
`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된
[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를
제공할 수 있다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
@ -128,9 +142,11 @@ spec:
`.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가
문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어
있음에 유의한다. 이 기능을 사용하지 않으려면 StatefulSetMinReadySeconds 플래그를 설정 해제한다.
있음에 유의한다. 이 기능을 사용하지 않으려면
StatefulSetMinReadySeconds 플래그를 설정 해제한다.
이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.)
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는
[컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
## 파드 신원
@ -166,8 +182,8 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다.
- DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다.
- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을
편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
[제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
파드의 네트워크 신원을 책임지는
@ -189,7 +205,9 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
### 안정된 스토리지
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
스테이트풀셋에 정의된 VolumeClaimTemplate 항목마다, 각 파드는 하나의
PersistentVolumeClaim을 받는다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@ -210,7 +228,9 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
* 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
* 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은
안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은
[스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
배포된다. web-1은 web-0이
@ -242,6 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
받지 않는다.
## 업데이트 전략
스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
@ -255,8 +276,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
`RollingUpdate`(롤링 업데이트)
: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
: `RollingUpdate` 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 기본 업데이트 전략이다.
## 롤링 업데이트

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

@ -1,6 +1,6 @@
---
# reviewers:
# - janetkuo
title: 완료된 잡 자동 정리
content_type: concept
weight: 70

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

@ -1,6 +1,6 @@
---
# reviewers:
# - erictune
title: 파드
content_type: concept
weight: 10
@ -320,12 +320,12 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
{{< api-reference page="workload-resources/pod-v1" >}}
오브젝트 정의는 오브젝트를 상세히 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns/)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽어본다.
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.

8
content/ko/docs/concepts/workloads/pods/disruptions.md
View File

@ -1,8 +1,8 @@
---
# reviewers:
# - erictune
# - foxish
# - davidopp
title: 중단(disruption)
content_type: concept
weight: 60

131
content/ko/docs/concepts/workloads/pods/downward-api.md Normal file
View File

@ -0,0 +1,131 @@
---
title: 다운워드(Downward) API
content_type: concept
description: >
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다.
환경 변수를 활용하거나, 그리고 특수한 볼륨 타입으로 채워진 파일을 이용한다.
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 다운워드 API라고 한다.
---
<!-- overview -->
컨테이너가 쿠버네티스에 지나치게 종속되지 않으면서도
자기 자신에 대한 정보를 알고 있으면 유용할 때가 있다.
*다운워드 API*는 컨테이너가 자기 자신 혹은 클러스터에 대한 정보를,
쿠버네티스 클라이언트나 API 서버 없이도 사용할 수 있게 한다.
예를 들어, 잘 알려진 특정 환경 변수에다가 고유한 식별자를 넣어 사용하는 애플리케이션이 있다고 하자.
해당 애플리케이션에 맞게 작업할 수도 있겠지만,
이는 지루하고 오류가 나기 쉬울뿐더러, 낮은 결합이라는 원칙에도 위배된다.
대신, 파드의 이름을 식별자로 사용하고
잘 알려진 환경 변수에 파드의 이름을 넣는 것도 괜찮은 방법이다.
쿠버네티스에는 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다.
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을
*다운워드 API*라고 한다.
<!-- body -->
## 사용 가능한 필드
쿠버네티스 API 필드 중 일부만이 다운워드 API를 통해 접근 가능하다.
이 페이지에서는 사용 가능한 필드를 나열한다.
사용 가능한 파드 필드에 대한 정보는 `fieldRef`를 통해 넘겨줄 수 있다.
API 레벨에서, 파드의 `spec`은 항상 하나 이상의
[컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)를 정의한다.
사용 가능한 컨테이너 필드에 대한 정보는
`resourceFiledRef`를 통해 넘겨줄 수 있다.
### `fieldRef`를 통해 접근 가능한 정보 {#downwardapi-fieldRef}
대부분의 파드 필드는 환경 변수로써,
또는 `다운워드 API` 볼륨을 사용하여 컨테이너에 제공할 수 있다.
이런 두 가지 방법을 통해 사용 가능한 필드는 다음과 같다.
`metadata.name`
: 파드의 이름
`metadata.namespace`
: 파드가 속한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}
`metadata.uid`
: 파드의 고유 ID
`metadata.annotations['<KEY>']`
: 파드의 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}에서 `<KEY>`에 해당하는 값 (예를 들어, `metadata.annotations['myannotation']`)
`metadata.labels['<KEY>']`
: 파드의 {{< glossary_tooltip text="레이블" term_id="label" >}}에서 `<KEY>`에 해당하는 문자열 (예를 들어, `metadata.labels['mylabel']`)
`spec.serviceAccountName`
: 파드의 {{< glossary_tooltip text="서비스 어카운트" term_id="service-account" >}}
`spec.nodeName`
: 파드가 실행중인 {{< glossary_tooltip term_id="node" text="노드">}}명
`status.hostIP`
: 파드가 할당된 노드의 기본 IP 주소
`status.podIP`
: 파드의 기본 IP 주소 (일반적으로 IPv4 주소)
추가적으로 아래 필드는 **환경 변수가 아닌**,
`다운워드 API` 볼륨의 `fieldRef`로만 접근 가능하다.
`metadata.labels`
: 파드의 모든 레이블로, 한 줄마다 하나의 레이블을 갖는(`label-key="escaped-label-value"`) 형식을 취함
`metadata.annotations`
: 파드의 모든 어노테이션으로, 한 줄마다 하나의 어노테이션을 갖는(`annotation-key="escaped-annotation-value"`) 형식을 취함
### `resourceFieldRef`를 통해 접근 가능한 정보 {#downwardapi-resourceFieldRef}
컨테이너 필드는 CPU와 메모리 같은 리소스에 대한
[요청 및 제한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)
값을 제공한다.
`resource: limits.cpu`
: 컨테이너의 CPU 제한
`resource: requests.cpu`
: 컨테이너의 CPU 요청
`resource: limits.memory`
: 컨테이너의 메모리 제한
`resource: requests.memory`
: 컨테이너의 메모리 요청
`resource: limits.hugepages-*`
: 컨테이너의 hugepage 제한 (`DownwardAPIHugePages` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화 된 경우)
`resource: requests.hugepages-*`
: 컨테이너의 hugepage 요청 (`DownwardAPIHugePages` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화 된 경우)
`resource: limits.ephemeral-storage`
: 컨테이너의 임시 스토리지 제한
`resource: requests.ephemeral-storage`
: 컨테이너의 임시 스토리지 요청
#### 리소스 제한에 대한 참고 정보
컨테이너의 CPU와 메모리 제한을 명시하지 않고
다운워드 API로 이 정보들을 제공하려고 할 경우,
kubelet은 기본적으로
[노드의 할당 가능량](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)에 기반하여
CPU와 메모리에 할당 가능한 최댓값을 노출시킨다.
## {{% heading "whatsnext" %}}
자세한 정보는 [`다운워드API` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)를 참고한다.
다운워드 API를 사용하여 파드 및 컨테이너 정보를 노출시켜보자.
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)

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

@ -1,7 +1,7 @@
---
# reviewers:
# - verb
# - yujuhong
title: 임시(Ephemeral) 컨테이너
content_type: concept
weight: 80

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

@ -1,6 +1,6 @@
---
# reviewers:
# - erictune
title: 초기화 컨테이너
content_type: concept
weight: 40
@ -115,7 +115,7 @@ kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
app.kubernetes.io/name: MyApp
spec:
containers:
- name: myapp-container
@ -159,7 +159,7 @@ kubectl describe -f myapp.yaml
Name: myapp-pod
Namespace: default
[...]
Labels: app=myapp
Labels: app.kubernetes.io/name=MyApp
Status: Pending
[...]
Init Containers:

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

@ -1,421 +0,0 @@
---
title: 파드 토폴로지 분배 제약 조건
content_type: concept
weight: 40
---
<!-- overview -->
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 {{< glossary_tooltip text="파드" term_id="Pod" >}}가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
<!-- body -->
## 필수 구성 요소
### 노드 레이블
토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. `node=node1,zone=us-east-1a,region=us-east-1`
다음 레이블이 있고, 4개 노드를 가지는 클러스터가 있다고 가정한다.
```
NAME STATUS ROLES AGE VERSION LABELS
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
```
그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
{{<mermaid>}}
graph TB
subgraph "zoneB"
n3(Node3)
n4(Node4)
end
subgraph "zoneA"
n1(Node1)
n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘 알려진 레이블](/ko/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
## 파드의 분배 제약 조건
### API
API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer>
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
```
사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
- `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수.
예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면,
전역 최솟값은 0)
사이에 허용되는 최대 차이이다.
- `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다.
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다.
"글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며,
적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
이 값은 스케줄링에 영향을 미치지 않는다.
- `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다.
- `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다.
{{< note >}}
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
이를 사용하려면 `MinDomainsInPodToplogySpread`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
- **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
- `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
- `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
- **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다.
### 예시: 단수 토폴로지 분배 제약 조건
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
`topologyKey: zone` 는 "zone:&lt;any value&gt;" 레이블 쌍을 가지는 노드에 대해서만 균등한 분배를 적용하는 것을 의미한다. `whenUnsatisfiable: DoNotSchedule` 은 만약 들어오는 파드가 제약 조건을 만족시키지 못하면 스케줄러에게 pending 상태를 유지하도록 지시한다.
만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
OR
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
p4(mypod) --> n3
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.
- `maxSkew` 를 "2" 보다 큰 값으로 변경해서 들어오는 파드들이 "zoneA"에도 배치할 수 있도록 한다.
- `topologyKey` 를 "node"로 변경해서 파드가 영역이 아닌, 노드에 걸쳐 고르게 분산할 수 있게 한다. 위의 예시에서 만약 `maxSkew` 가 "1"로 유지되면 들어오는 파드는 오직 "node4"에만 배치할 수 있다.
- `whenUnsatisfiable: DoNotSchedule` 에서 `whenUnsatisfiable: ScheduleAnyway` 로 변경하면 들어오는 파드는 항상 다른 스케줄링 API를 충족한다는 가정하에 스케줄할 수 있도록 보장한다. 그러나 일치하는 파드가 적은 토폴로지 도메인에 배치되는 것이 좋다. (이 선호도는 리소스 사용 비율 등과 같은 다른 내부 스케줄링 우선순위와 공동으로 정규화 된다는 것을 알아두자.)
### 예시: 다중 토폴로지 분배 제약 조건
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
이 경우에는, 첫 번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p4(Pod) --> n3(Node3)
p5(Pod) --> n3
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n1
p3(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s;
class zoneA,zoneB cluster;
{{< /mermaid >}}
만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 `Pending` 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.
이 상황을 극복하기 위해서는 사용자가 `maxSkew` 의 증가 또는 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 제약 조건 중 하나를 수정할 수 있다.
### 노드 어피니티(Affinity) 및 노드 셀렉터(Selector)와의 상호 작용
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
### 예시: TopologySpreadConstraints와 노드 어피니티
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
{{<mermaid>}}
graph BT
subgraph "zoneB"
p3(Pod) --> n3(Node3)
n4(Node4)
end
subgraph "zoneA"
p1(Pod) --> n1(Node1)
p2(Pod) --> n2(Node2)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n1,n2,n3,n4,p1,p2,p3 k8s;
class p4 plain;
class zoneA,zoneB cluster;
{{< /mermaid >}}
{{<mermaid>}}
graph BT
subgraph "zoneC"
n5(Node5)
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class n5 k8s;
class zoneC cluster;
{{< /mermaid >}}
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다.
### 기타 눈에 띄는 의미(semantics)
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
### 클러스터 수준의 기본 제약 조건
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
레플리카셋 또는 스테이트풀셋에서 계산한다.
예시 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
defaultingType: List
```
{{< note >}}
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
기본적으로 비활성화되어 있다.
비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
{{< /note >}}
#### 내장 기본 제약 {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다.
```yaml
defaultConstraints:
- maxSkew: 3
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: ScheduleAnyway
- maxSkew: 5
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
```
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은
기본적으로 비활성화되어 있다.
{{< note >}}
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
없는 노드에 점수를 매기지 않는다.
이로 인해 기본 토폴로지 제약을 사용하는 경우의
레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
대신 자체 제약 조건을 정의한다.
{{< /note >}}
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
`PodTopologySpread` 플러그인 구성에서 `defaultingType` 을 `List` 로 설정하고
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []
defaultingType: List
```
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다.
- `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에
원하는 수의 파드를 얼마든지 채울 수 있다.
- `PodAntiAffinity` 로는, 단일 토폴로지 도메인에
단 하나의 파드만 스케줄 될 수 있다.
더 세밀한 제어를 위해, 토폴로지 분배 제약 조건을 지정하여 다양한 토폴로지 도메인에 파드를
분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을
제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은
[모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를
참고한다.
## 알려진 제한사항
- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다. 예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다.
[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다.
- 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
## {{% heading "whatsnext" %}}
- [블로그: PodTopologySpread 소개](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/)에서는
`maxSkew` 에 대해 자세히 설명하고, 몇 가지 고급 사용 예제를 제공한다.

19
content/ko/docs/contribute/localization_ko.md
View File

@ -89,21 +89,21 @@ content_type: concept
즉, 원문이 한 문단을 줄바꿈하지 않고 한 행에 길게 기술했다면 한글화 시에도 한 행에 길게 기술하고, 원문이 한 문단을
줄바꿈해서 여러 행으로 기술한 경우에는 한글화 시에도 가로폭을 원문과 비슷하게 유지한다.
### 리뷰어 삭제
### 리뷰어 주석 처리
때때로 원문의 코드 상단에 리뷰어가 명시되어 있는 경우가 있다. 일반적으로 원문 페이지의 리뷰어가 한글화 된 페이지를 리뷰하기 어려우므로 리소스 메타데이터에서 리뷰어 관련 코드를
삭제한다.
주석 처리한다.
아래는 리뷰어 관련 코드를 삭제하는 예시를 보여준다.
아래는 리뷰어 관련 코드를 주석 처리하는 예시를 보여준다.
```diff
- reviews:
- - reviewer1
- - reviewer
- title: Kubernetes Components
+
+
+
+ # reviews:
+ # - reviewer1
+ # - reviewer
+ title: 쿠버네티스 컴포넌트
content_type: concept
weight: 10
@ -260,6 +260,7 @@ beta | 베타 |
Binding | 바인딩(Binding) | API 오브젝트인 경우
boilerplate | 상용구 |
Boot | 부트 |
Bootstrap | 부트스트랩 |
Build | 빌드 |
Cache | 캐시 |
Calico | 캘리코(Calico) |
@ -321,6 +322,7 @@ extension | 익스텐션(extension) |
Failed | Failed | 파드의 상태에 한함
Federation | 페더레이션 |
field | 필드 |
finalizer | 파이널라이저(finalizer) |
Flannel | 플란넬(Flannel) |
form | 형식 |
Google Compute Engine | Google Compute Engine |
@ -379,10 +381,13 @@ NetworkPolicy | 네트워크폴리시(NetworkPolicy) | API 오브젝트인 경
Node | 노드(Node) | API 오브젝트인 경우
node lease | 노드 리스(lease)
Object | 오브젝트 |
observability | 가시성(observability) |
Operator | 오퍼레이터 | [쿠버네티스의 소프트웨어 익스텐션](https://kubernetes.io/ko/docs/concepts/extend-kubernetes/operator/)을 의미하는 경우
Orchestrate | 오케스트레이션하다 |
Output | 출력 |
parameter | 파라미터 |
patch | 패치 |
payload | 페이로드(payload) |
Pending | Pending | 파드, 클레임의 상태에 한함
PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 경우
PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우
@ -445,6 +450,7 @@ Session | 세션 |
Session Affinity | 세션 어피니티(Affinity) |
Setting | 세팅 |
Shell | 셸 |
sidecar | 사이드카(sidecar) |
Sign In | 로그인 |
Sign Out | 로그아웃 |
skew | 차이(skew) |
@ -462,6 +468,7 @@ Surge | 증가율 | 롤링업데이트 전략에 한함
System | 시스템 |
taint | 테인트(taint) |
Task | 태스크 |
telepresence | 텔레프레즌스(telepresence) |
Terminated | Terminated | 파드의 상태에 한함
TokenReview | 토큰리뷰(TokenReview) | API 오브젝트인 경우
tolerations | 톨러레이션(toleration) |

16
content/ko/docs/contribute/new-content/open-a-pr.md
View File

@ -216,16 +216,16 @@ class changes,changes2 white
1. 작업할 브랜치 기반을 결정한다.
- 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
- 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
- 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다.
- 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
- 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
- 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다.
자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
- 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
해당 작업을 위해 작성된 특정 기능 브랜치를
사용한다.
- 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
해당 작업을 위해 작성된 특정 기능 브랜치를
사용한다.
브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다.
이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.

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

@ -10,8 +10,7 @@ weight: 10
누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다.
쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다.
문서화에 대한 풀 리퀘스트를 리뷰하는 것은
쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다.
문서화에 대한 풀 리퀘스트를 리뷰하는 것은 쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다.
아울러, 코드 베이스(code base)를 배우고 다른 기여자와 신뢰를 구축하는 데 도움이 된다.
리뷰하기 전에, 다음을 수행하는 것이 좋다.
@ -28,7 +27,6 @@ weight: 10
리뷰를 시작하기 전에 다음을 명심하자.
- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고
항상 준수한다.
- 정중하고, 사려 깊고, 도움이 되자.
@ -73,6 +71,7 @@ class third,fourth white
그림 1. 리뷰 과정 절차.
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다.
쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 표시된다.

4
content/ko/docs/home/_index.md
View File

@ -1,6 +1,6 @@
---
# approvers:
# - chenopis
title: 쿠버네티스 문서
noedit: true
cid: docsHome

2
content/ko/docs/images/ingress.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

2
content/ko/docs/images/ingressFanOut.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 14 KiB

2
content/ko/docs/images/ingressNameBased.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

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

@ -1,7 +1,7 @@
---
title: 레퍼런스
# approvers:
# - chenopis
linkTitle: "레퍼런스"
main_menu: true
weight: 70
@ -86,7 +86,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
[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/)
* [이미지 정책 API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/)

4
content/ko/docs/reference/access-authn-authz/_index.md
View File

@ -10,7 +10,7 @@ no_list: true
참조 문헌
- [인증](/docs/reference/access-authn-authz/authentication/)
- [부트스트랩 토큰 인증](/docs/reference/access-authn-authz/bootstrap-tokens/)
- [부트스트랩 토큰 인증](/ko/docs/reference/access-authn-authz/bootstrap-tokens/)
- [승인 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
- [동적 승인 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
@ -24,5 +24,5 @@ no_list: true
- 서비스 어카운트
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
- [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
- [kubelet 인증과 인가](/docs/reference/access-authn-authz/kubelet-authn-authz/)
- [kubelet 인증과 인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)
- kubelet [TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함함

22
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -1,9 +1,9 @@
---
# reviewers:
# - erictune
# - lavalamp
# - deads2k
# - liggitt
title: 인가 개요
content_type: concept
weight: 60
@ -74,6 +74,10 @@ PUT | update
PATCH | patch
DELETE | delete(개별 리소스), deletecollection(리소스 모음)
{{< caution >}}
`get`, `list`, `watch` 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 `secrets`에 대해 `list` 요청은 반환된 리소스의 `data` 속성을 여전히 드러낼 것이다.
{{< /caution >}}
쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)
@ -134,7 +138,7 @@ kubectl auth can-i list secrets --namespace dev --as dave
no
```
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가
`target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.
```bash
@ -209,7 +213,7 @@ status:
## 워크로드 생성 및 수정을 통한 권한 확대 {#privilege-escalation-via-pod-creation}
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.
{{< caution >}}
@ -230,8 +234,8 @@ status:
- 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음
{{< caution >}}
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다.
{{< /caution >}}

190
content/ko/docs/reference/access-authn-authz/bootstrap-tokens.md Normal file
View File

@ -0,0 +1,190 @@
---
# reviewers:
# jbeda
title: 부트스트랩 토큰을 사용한 인증
content_type: concept
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
부트스트랩 토큰은 새 클러스터를 만들거나 새 노드를 기존 클러스터에 결합할 때
사용되는 간단한 전달자 토큰이다.
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)을 지원하도록 구축되었지만
`kubeadm` 없이 클러스터를 시작하려는 사용자를 위해 다른 컨텍스트에서 사용할 수 있다.
또한 RBAC 정책을 통해 [Kubelet TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
시스템과 함께 동작하도록 구축되었다.
<!-- body -->
## 부트스트랩 토큰 개요
부트스트랩 토큰은 `kube-system` 네임스페이스에 있는
특정 유형(`bootstrap.kubernetes.io/token`)의 시크릿(Secret)으로 정의된다.
API 서버의 부트스트랩 인증자가 이러한 시크릿을 읽는다.
만료된 토큰은 컨트롤러 관리자가 TokenCleaner 컨트롤러로 제거한다.
토큰은 BootstrapSigner 컨트롤러를 통해
"discovery" 프로세스에 사용되는 특정 컨피그맵(ConfigMap)에 대한
서명을 만드는 데도 사용된다.
## 토큰 형식
부트스트랩 토큰은 `abcdef.0123456789abcdef` 형식을 취한다. 더 공식적으로는
정규식 `[a-z0-9]{6}\.[a-z0-9]{16}` 와 일치해야 한다.
토큰의 첫 번째 부분은 "Token ID" 이며 공개 정보로 간주된다.
인증에 사용하는 시크릿의 일부를 노출하지 않고 토큰을 참조할 때 사용한다.
두 번째 부분은 "Token Secret"이며
신뢰할 수 있는 당사자와만 공유해야 한다.
## 부트스트랩 토큰 인증 활성화
API 서버에서 다음 플래그를 사용하여 부트스트랩 토큰 인증자를
활성화할 수 있다.
```
--enable-bootstrap-token-auth
```
활성화되면 부트스트랩 토큰을 API 서버에 대한 요청을 인증하기 위한
전달자 토큰 자격 증명으로 사용할 수 있다.
```http
Authorization: Bearer 07401b.f395accd246ae52d
```
토큰은 사용자 이름 `system:bootstrap:<token id>` 로 인증되며 `system:bootstrappers` 그룹의 구성원이다.
토큰의 시크릿에 추가 그룹을
지정할 수 있다.
만료된 토큰은 컨트롤러 관리자에서 `tokencleaner`
컨트롤러를 활성화하여 자동으로 삭제할 수 있다.
```
--controllers=*,tokencleaner
```
## 부트스트랩 토큰 시크릿 형식
각각의 유효한 토큰은 `kube-system` 네임스페이스의 시크릿에 의해 지원된다.
전체 디자인 문서는
[여기](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md)에서 찾을 수 있다.
시크릿은 다음과 같다.
```yaml
apiVersion: v1
kind: Secret
metadata:
# Name MUST be of form "bootstrap-token-<token id>"
name: bootstrap-token-07401b
namespace: kube-system
# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
# Human readable description. Optional.
description: "The default bootstrap token generated by 'kubeadm init'."
# Token ID and secret. Required.
token-id: 07401b
token-secret: f395accd246ae52d
# Expiration. Optional.
expiration: 2017-03-10T03:22:11Z
# Allowed usages.
usage-bootstrap-authentication: "true"
usage-bootstrap-signing: "true"
# Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
```
시크릿 유형은 `bootstrap.kubernetes.io/token` 이어야 하고
이름은 `bootstrap-token-<token id>`여야 한다. 반드시 `kube-system`
네임스페이스에도 존재해야 한다.
`usage-bootstrap-*` 멤버는 이 시크릿의 용도를 나타낸다.
활성화하려면 값을 `true` 로 설정해야 한다.
* `usage-bootstrap-authentication` 은 토큰을 API 서버에
베어러 토큰으로 인증하는데 사용할 수 있음을 나타낸다.
* `usage-bootstrap-signing` 은 토큰을 사용하여 아래에 설명된
`cluster-info` 컨피그맵에 서명할 수 있음을 나타낸다.
`expiration` 필드는 토큰의 만료를 제어한다. 만료된 토큰은
인증에 사용될 때 거부되고 컨피그맵서명 중에 무시된다.
만료된 값은 RFC3339를 사용하여 절대 UTC 시간으로 인코딩된다.
만료된 토큰을 자동으로 삭제하려면 `tokencleaner` 컨트롤러를 활성화한다.
## kubeadm을 사용한 토큰 관리
`kubeadm` 툴을 사용하여 실행중인 클러스터에서 토큰을 관리할 수 있다.
자세한 내용은 [kubeadm token docs](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 에서 찾을 수 있다.
## 컨피그맵 서명
토큰은 인증 외에도 컨피그맵에 서명하는데 사용할 수 있다.
이것은 클라이언트가 API 서버를 신뢰하기 전에 클러스터 부트스트랩 프로세스의 초기에 사용된다.
서명된 컨피그맵은 공유 토큰으로 인증할 수 있다.
컨트롤러 관리자에서 `bootstrapsigner` 컨트롤러를 활성화하여
컨피그맵서명을 활성화 한다.
```
--controllers=*,bootstrapsigner
```
서명된 컨피그맵은 `kube-public` 네임스페이스에 있는 `cluster-info` 이다.
일반적인 흐름은 클라이언트가 인증되지 않고 TLS 오류를 무시하는 동안
컨피그맵을 읽는 것이다. 그런 다음 컨피그맵에 포함된 서명을 확인하여
컨피그맵의 페이로드를 확인한다.
컨피그맵은 다음과 같을 수 있다.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-info
namespace: kube-public
data:
jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
kubeconfig: |
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <really long certificate data>
server: https://10.138.0.2:6443
name: ""
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []
```
컨피그맵의 `kubeconfig` 멤버는 클러스터 정보만 입력된 구성 파일이다.
여기서 전달되는 핵심은 `certificate-authority-data` 이다.
이는 향후 확대될 수 있다.
서명은 "detached" 모드를 사용하는 JWS 서명이다. 서명을 검증하려면
사용자는 JWS 규칙(뒤로 오는 `=` 를 삭제하는 동안 인코딩된 base64)에 따라
`kubeconfig` 페이로드를 인코딩해야 한다. 그런 다음 인코딩된 페이로드는
두 개의 점 사이에 삽입하여 전체 JWS를 형성하는 데 사용된다.
전체 토큰(예:`07401b.f395accd246ae52d`)을 공유 시크릿으로 사용하여
`HS256` 방식(HMAC-SHA256)을 사용함으로 JWS를 확인할 수 있다.
사용자는 _반드시_ HS256이 사용되고 있는지 확인해야 한다.
{{< warning >}}
부트스트래핑 토큰을 가진 모든 당사자는 해당 토큰에 대한 유효한 서명을 만들 수 있다.
컨피그맵 서명을 사용할 때 많은 클라이언트와 동일한 토큰을 공유하는 것은 권장되지 않는다.
손상된 클라이언트는 잠재적으로 서명에 의존하여
TLS 트러스트를 부트스트랩하는 다른 클라이언트를 대신할 수 있기 때문이다.
{{< /warning >}}
자세한 내용은 [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/)
섹션을 참조하면 된다.

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