Merge pull request #35767 from kubernetes/dev-1.24-ko.2
[ko] 2nd Korean localization work for v1.24pull/35832/head
Kubernetes Prow Robot
GitHub
commit
a516999278
|
|
@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
|
|||
<button id="desktopShowVideoButton" onclick="kub.showVideo()">비디오 보기</button>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">KubeCon Europe (2022년 5월 17~20일) 참가하기</a>
|
||||
<br>
|
||||
<br>
|
||||
<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>
|
||||
<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>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,179 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "쿠버네티스 1.24: gRPC 컨테이너 프로브 베타"
|
||||
date: 2022-05-13
|
||||
slug: grpc-probes-now-in-beta
|
||||
---
|
||||
|
||||
**저자**: Sergey Kanzhelev (Google)
|
||||
|
||||
**번역**: 송원석 (쏘카), 손석호 (ETRI), 김상홍 (국민대), 김보배 (11번가)
|
||||
|
||||
쿠버네티스 1.24에서 gRPC 프로브 기능이 베타에 진입했으며 기본적으로 사용 가능하다.
|
||||
이제 HTTP 엔드포인트를 노출하지 않고, gRPC 앱에 대한 스타트업(startup), 활성(liveness) 및 준비성(readiness) 프로브를 구성할 수 있으며,
|
||||
실행 파일도 필요하지 않는다. 쿠버네티스는 기본적으로 gRPC를 통해 워크로드에 자체적으로(natively) 연결 가능하며, 상태를 쿼리할 수 있다.
|
||||
|
||||
## 약간의 히스토리
|
||||
|
||||
시스템이 워크로드의 앱이 정상인지, 정상적으로 시작되었는지,
|
||||
트래픽을 수용할 수 있는지에 대해 관리하는 것은 유용하다.
|
||||
gRPC 지원이 추가되기 전에도, 쿠버네티스는 이미 컨테이너 이미지
|
||||
내부에서 실행 파일을 실행하거나, HTTP 요청을 하거나,
|
||||
TCP 연결이 성공했는지 여부를 확인하여 상태를 확인할 수 있었다.
|
||||
|
||||
대부분의 앱은, 이러한 검사로 충분하다. 앱이 상태(또는 준비성) 확인을
|
||||
위한 gRPC 엔드포인트를 제공하는 경우 `exec` 프로브를
|
||||
gRPC 상태 확인에 사용하도록 쉽게 용도를 변경할 수 있다.
|
||||
블로그 기사 [쿠버네티스의 gRPC 서버 상태 확인](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)에서, Ahmet Alp Balkan은 이를 수행하는 방법을 설명하였으며, 이는 지금도 여전히 작동하는 메커니즘이다.
|
||||
|
||||
이것을 활성화하기 위해 일반적으로 사용하는 도구는 2018년 8월 21일에 [생성](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)되었으며, 이 도구의 첫 릴리즈는 [2018년 9월 19일](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1)에 나왔다.
|
||||
|
||||
gRPC 앱 상태 확인을 위한 이 접근 방식은 매우 인기있다. `grpc_health_probe`를 포함하고 있는 [Dockerfile은 3,626개](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)이며, (문서 작성 시점에)GitHub의 기본 검색으로 발견된 [yaml 파일은 6,621개](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code)가 있다. 이것은 도구의 인기와 이를 기본적으로 지원해야 할 필요성을 잘 나타낸다.
|
||||
|
||||
쿠버네티스 v1.23은 gRPC를 사용하여 워크로드 상태를 쿼리하는 기본(native) 지원을 알파 수준의 구현으로 기본 지원으로 도입 및 소개했다. 알파 기능이었기 때문에 v1.23 릴리스에서는 기본적으로 비활성화되었다.
|
||||
|
||||
## 기능 사용
|
||||
|
||||
우리는 다른 프로브와 유사한 방식으로 gRPC 상태를 확인할 수 있도록 구축했으며, 쿠버네티스의 다른 프로브에 익숙하다면 [사용하기 쉬울 것](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)이라 믿는다.
|
||||
자체적으로 지원되는 상태 프로브는 `grpc_health_probe` 실행 파일과 관련되어 있던 차선책에 비해 많은 이점이 있다.
|
||||
|
||||
기본 gRPC 지원을 사용하면 이미지에 `10MB`의 추가 실행 파일을 다운로드하여 저장할 필요가 없다.
|
||||
Exec 프로브는 실행 파일을 실행하기 위해 새 프로세스를 인스턴스화해야 하므로 일반적으로 gRPC 호출보다 느리다.
|
||||
또한 파드가 리소스 최대치로 실행 중이고 새 프로세스를 인스턴스화하는데 문제가 있는 경우에는 검사의 분별성을 낮추게 만든다.
|
||||
|
||||
그러나 여기에는 몇 가지 제약이 있다. 프로브용 클라이언트 인증서(certificate)를 구성하는 것이 어렵기 때문에, 클라이언트 인증(authentication)이 필요한 서비스는 지원하지 않는다. 기본 제공(built-in) 프로브도 서버 인증서를 확인하지 않고 관련 문제를 무시한다.
|
||||
|
||||
또한 기본 제공 검사는 특정 유형의 오류를 무시하도록 구성할 수 없으며 (`grpc_health_probe`는 다른 오류에 대해 다른 종료 코드를 반환함), 단일 프로브에서 여러 서비스 상태 검사를 실행하도록 "연계(chained)"할 수 없다.
|
||||
|
||||
그러나 이러한 모든 제한 사항은 gRPC에서 꽤 일반적이며 이에 대한 쉬운 해결 방법이 있다.
|
||||
|
||||
## 직접 해 보기
|
||||
|
||||
### 클러스터 수준의 설정
|
||||
|
||||
오늘 이 기능을 사용해 볼 수 있다. 기본 gRPC 프로브 사용을 시도하려면, `GRPCContainerProbe` 기능 게이트를 활성화하여 쿠버네티스 클러스터를 직접 가동한다. [가용한 도구](/ko/docs/tasks/tools/)가 많이 있다.
|
||||
|
||||
기능 게이트 `GRPCContainerProbe`는 1.24에서 기본적으로 활성화되어 있으므로, 많은 공급업체가 이 기능을 즉시 사용 가능하도록 제공할 것이다.
|
||||
따라서 선택한 플랫폼에서 1.24 클러스터를 그냥 생성하면 된다. 일부 공급업체는 1.23 클러스터에서 알파 기능을 사용 할 수 있도록 허용한다.
|
||||
|
||||
예를 들어, 빠른 테스트를 위해 GKE에서 테스트 클러스터를 가동할 수 있다. (해당 문서 작성 시점 기준)
|
||||
다른 공급업체도 유사한 기능을 가지고 있을 수 있다. 특히 쿠버네티스 1.24 릴리스 이후 이 블로그 게시물을 읽고 있는 경우에는 더욱 그렇다.
|
||||
|
||||
GKE에서 다음 명령어를 사용한다. (참고로 버전은 `1.23`이고 `enable-kubernetes-alpha`가 지정됨).
|
||||
|
||||
```shell
|
||||
gcloud container clusters create test-grpc \
|
||||
--enable-kubernetes-alpha \
|
||||
--no-enable-autorepair \
|
||||
--no-enable-autoupgrade \
|
||||
--release-channel=rapid \
|
||||
--cluster-version=1.23
|
||||
```
|
||||
|
||||
또한 클러스터에 접근하기 위해서 `kubectl`을 구성할 필요가 있다.
|
||||
|
||||
```shell
|
||||
gcloud container clusters get-credentials test-grpc
|
||||
```
|
||||
|
||||
### 기능 사용해 보기
|
||||
|
||||
gRPC 프로브가 작동하는 방식을 테스트하기 위해 파드를 생성해 보겠다. 이 테스트에서는 `agnhost` 이미지를 사용한다.
|
||||
이것은 모든 종류의 워크로드 테스트에 사용할 수 있도록, k8s가 유지 관리하는 이미지다.
|
||||
예를 들어, 두 개의 포트를 노출하는 유용한 [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) 모듈을 가지고 있다. 하나는 상태 확인 서비스를 제공하고 다른 하나는 `make-serving` 및 `make-not-serving` 명령에 반응하는 http 포트다.
|
||||
|
||||
다음은 파드 정의의 예시이다. 이 예시는 `grpc-health-checking` 모듈을 시작하고, 포트 `5000` 및 `8080`을 노출하며, gRPC 준비성 프로브를 구성한다.
|
||||
|
||||
``` yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: test-grpc
|
||||
spec:
|
||||
containers:
|
||||
- name: agnhost
|
||||
image: k8s.gcr.io/e2e-test-images/agnhost:2.35
|
||||
command: ["/agnhost", "grpc-health-checking"]
|
||||
ports:
|
||||
- containerPort: 5000
|
||||
- containerPort: 8080
|
||||
readinessProbe:
|
||||
grpc:
|
||||
port: 5000
|
||||
```
|
||||
|
||||
`test.yaml`이라는 파일이 있으면, 파드를 생성하고 상태를 확인할 수 있다. 파드는 아래 출력 스니펫(snippet)에 표시된 대로 준비(ready) 상태가 된다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f test.yaml
|
||||
kubectl describe test-grpc
|
||||
```
|
||||
|
||||
출력에는 다음과 같은 내용이 포함된다.
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready True
|
||||
ContainersReady True
|
||||
PodScheduled True
|
||||
```
|
||||
|
||||
이제 상태 확인 엔드포인트 상태를 NOT_SERVING으로 변경해 보겠다.
|
||||
파드의 http 포트를 호출하기 위해 포트 포워드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl port-forward test-grpc 8080:8080
|
||||
```
|
||||
|
||||
명령을 호출하기 위해 `curl`을 사용할 수 있다 ...
|
||||
|
||||
```shell
|
||||
curl http://localhost:8080/make-not-serving
|
||||
```
|
||||
|
||||
... 그리고 몇 초 후에 포트 상태가 준비되지 않음으로 전환된다.
|
||||
|
||||
```shell
|
||||
kubectl describe pod test-grpc
|
||||
```
|
||||
|
||||
이제 다음과 같은 출력을 확인할 수 있을 것이다.
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready False
|
||||
ContainersReady False
|
||||
PodScheduled True
|
||||
...
|
||||
Warning Unhealthy 2s (x6 over 42s) kubelet Readiness probe failed: service unhealthy (responded with "NOT_SERVING")
|
||||
```
|
||||
|
||||
다시 전환되면, 약 1초 후에 파드가 준비(ready) 상태로 돌아간다.
|
||||
|
||||
``` bsh
|
||||
curl http://localhost:8080/make-serving
|
||||
kubectl describe test-grpc
|
||||
```
|
||||
|
||||
아래 출력은 파드가 다시 `Ready` 상태로 돌아갔다는 것을 나타낸다.
|
||||
|
||||
```
|
||||
Conditions:
|
||||
Type Status
|
||||
Initialized True
|
||||
Ready True
|
||||
ContainersReady True
|
||||
PodScheduled True
|
||||
```
|
||||
|
||||
쿠버네티스에 내장된 이 새로운 gRPC 상태 프로브를 사용하면 별도의 `exec` 프로브를 사용하는 이전 접근 방식보다 gRPC를 통한 상태 확인을 훨씬 쉽게 구현할 수 있다. 더 자세한 내용 파악을 위해 공식 [문서](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 자세히 살펴보고, 기능이 GA로 승격되기 전에 피드백을 제공하길 바란다.
|
||||
|
||||
## 요약
|
||||
|
||||
쿠버네티스는 인기 있는 워크로드 오케스트레이션 플랫폼이며 피드백과 수요를 기반으로 기능을 추가한다.
|
||||
gRPC 프로브 지원과 같은 기능은 많은 앱 개발자의 삶을 더 쉽게 만들고 앱을 더 탄력적으로 만들 수 있는 마이너한 개선이다. 오늘 기능을 사용해보고 기능이 GA로 전환되기 전에 오늘 사용해 보고 피드백을 제공해보자.
|
||||
|
|
@ -8,8 +8,8 @@ community_styles_migrated: true
|
|||
<div class="community-section" id="cncf-code-of-conduct-intro">
|
||||
<p>
|
||||
쿠버네티스는
|
||||
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
|
||||
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">커밋 214585e</a>
|
||||
<a href="https://github.com/cncf/foundation/blob/main/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
|
||||
<a href="https://github.com/cncf/foundation/blob/71b12a2f8b4589788ef2d69b351a3d035c68d927/code-of-conduct.md">커밋 71b12a2</a>
|
||||
에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다.
|
||||
만약 최신 버전이 아닌 경우에는
|
||||
<a href="https://github.com/kubernetes/website/issues/new">이슈를 제기해 주세요</a>.
|
||||
|
|
|
|||
|
|
@ -1,28 +1,42 @@
|
|||
<!-- Do not edit this file directly. Get the latest from
|
||||
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
|
||||
## CNCF 커뮤니티 행동 강령 v1.0
|
||||
https://github.com/cncf/foundation/blob/main/code-of-conduct.md -->
|
||||
## CNCF 커뮤니티 행동 강령 v1.1
|
||||
|
||||
### 기여자 행동 강령
|
||||
|
||||
본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
|
||||
CNCF 커뮤니티의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
|
||||
커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트,
|
||||
풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는
|
||||
모든 분들을 존중할 것을 약속합니다.
|
||||
|
||||
우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression),
|
||||
성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교,
|
||||
또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에
|
||||
또는 국적에 상관 없이 모두가 차별 없는 환경에서 CNCF 커뮤니티에
|
||||
참여할 수 있도록 최선을 다하고 있습니다.
|
||||
|
||||
## 범위
|
||||
본 행동 강령은 프로젝트 활동 영역 내에서뿐만 아니라 개인이 프로젝트 또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
|
||||
|
||||
## CNCF 이벤트
|
||||
CNCF 이벤트, 혹은 리눅스 재단에서 이벤트 전문 직원과 운영하는 이벤트는 이벤트 페이지에 명시된 Linux Foundation [이벤트 행동 강령](https://events.linuxfoundation.org/code-of-conduct)에 의거하여 운영됩니다. 해당 행동 강령은 CNCF의 행동 강령과 함께 사용하도록 고안되었습니다.
|
||||
|
||||
## 우리의 원칙
|
||||
|
||||
긍정적인 환경을 조성하는 행위는 다음과 같습니다.
|
||||
* 타인에게 친절과 공감 실천
|
||||
* 타인의 의견, 관점, 그리고 경험에 대한 포용
|
||||
* 건설적 피드백에 대한 수용
|
||||
* 실수에 대한 책임과 사과, 그리고 경험을 통한 배움
|
||||
* 개인의 최선이 아닌 커뮤니티 전반의 선을 위한 노력
|
||||
|
||||
|
||||
참여자에게 금지하는 행위의 예시는 다음과 같습니다.
|
||||
|
||||
- 성적인 언어 또는 이미지 사용
|
||||
- 인신 공격
|
||||
- 도발적이거나 모욕/경멸적인 코멘트
|
||||
- 공개적이거나 사적인 괴롭힘
|
||||
- 타인의 주소 및 전자주소와 같은 개인 정보의
|
||||
동의 없는 공개
|
||||
- 기타 비윤리적이거나 비전문적인 행동
|
||||
* 성적인 언어 또는 이미지 사용, 혹은 그 외 성적으로 부적절한 행동
|
||||
* 선동적, 모욕적, 경멸적 언사, 그리고 개인적 혹은 정치적 공격
|
||||
* 공개적이거나 사적인 괴롭힘
|
||||
* 타인의 주소 및 전자주소와 같은 개인 정보의 동의 없는 공개
|
||||
* 기타 비윤리적이거나 비전문적인 행동
|
||||
|
||||
프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit),
|
||||
코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정,
|
||||
|
|
@ -31,15 +45,22 @@
|
|||
행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서
|
||||
영구적으로 제적될 수 있습니다.
|
||||
|
||||
본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트
|
||||
또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
|
||||
## 신고
|
||||
쿠버네티스 커뮤니티에서 발생하는 사건들은 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 신고시 3일 내 회신을 받을 수 있습니다.
|
||||
|
||||
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의해 주시기 바랍니다.
|
||||
기타 다른 프로젝트에 관해서는 CNCF 직원에게 이메일 <conduct@cncf.io>으로 문의하십시오.
|
||||
|
||||
본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서
|
||||
제공하는 버전 1.2.0을 적용하였으며, 해당 내용은
|
||||
https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다.
|
||||
CNCF는 외부 중재자로 Mishi Choudhary <mishi@linux.com>를 두고 있습니다. 외부 중재자는 CNCF 직원의 안내에 따라 의뢰 가능합니다. 보통의 경우 <conduct@cncf.io>로 직접 연락하는 것을 추천합니다.
|
||||
|
||||
### CNCF 이벤트 행동 강령
|
||||
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의하십시오.
|
||||
|
||||
CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다.
|
||||
## 집행
|
||||
쿠버네티 프로젝트의 [행동 강령 위원회](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)가 행동 강령 발행을 시행합니다. 기타 프로젝트에 관하여는 CNCF가 행동강력 발행을 시행합니다.
|
||||
|
||||
양 기관은 처벌 없는 문제 해결을 추구합니다. 하지만 CNCF의 재량에 따라 회원 혹은 프로젝트를 퇴출시킬 수 있습니다.
|
||||
|
||||
### 확인
|
||||
|
||||
본 행동 강령은 기여자 서약(https://contributor-covenant.org)에서
|
||||
제공하는 버전 2.0을 적용하였으며, 해당 내용은
|
||||
https://contributor-covenant.org/version/2/0/code_of_conduct/ 에서 확인할 수 있습니다.
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@ weight: 40
|
|||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
|
||||
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를
|
||||
클라우드 인프라스트럭처 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
|
||||
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭처를
|
||||
신뢰한다.
|
||||
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="클라우드 컨트롤러 매니저는">}}
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
|
||||
이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
|
||||
|
||||
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증
|
|||
API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
|
||||
|
||||
* 파드에 대한 로그를 가져온다.
|
||||
* 실행 중인 파드에 (kubectl을 통해) 연결한다.
|
||||
* 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다.
|
||||
* kubelet의 포트-포워딩 기능을 제공한다.
|
||||
|
||||
이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
|
||||
|
|
@ -58,9 +58,11 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로
|
|||
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
|
||||
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
|
||||
|
||||
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
|
||||
{{< note >}}
|
||||
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 대체한다.
|
||||
{{< note >}}
|
||||
|
||||
### Konnectivity 서비스
|
||||
### Konnectivity 서비스 {#konnectivity-service}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -654,6 +654,6 @@ kubelet은 `LimitedSwap` 설정과 같은 행동을
|
|||
|
||||
* 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
|
||||
* [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다.
|
||||
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
|
||||
섹션을 읽어본다.
|
||||
* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ no_list: true
|
|||
|
||||
### kubelet 보안
|
||||
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
|
||||
## 선택적 클러스터 서비스
|
||||
|
|
|
|||
|
|
@ -18,19 +18,19 @@ content_type: concept
|
|||
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
|
||||
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
|
||||
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
|
||||
* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
|
||||
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
|
||||
* [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
|
||||
* [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
|
||||
* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
|
||||
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
|
||||
* **Romana**는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
|
||||
* [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
|
||||
|
||||
## 서비스 검색
|
||||
|
|
|
|||
|
|
@ -454,7 +454,7 @@ deployment.apps/my-nginx scaled
|
|||
kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/concepts/workloads/controllers/deployment/)를 방문한다.
|
||||
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/tasks/debug/debug-application/debug-running-pod/)를 방문한다.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -202,5 +202,5 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
|
||||
[네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에
|
||||
[네트워킹 디자인 문서](https://git.k8s.io/design-proposals-archive/network/networking.md)에
|
||||
자세히 설명되어 있다.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
|
|||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다.
|
||||
신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다.
|
||||
신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다.
|
||||
{{< /warning>}}
|
||||
|
||||
|
|
@ -150,16 +150,16 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
|
|||
|
||||
## 프록시
|
||||
|
||||
다음과 같이 kubeconfig 파일에 `proxy-url`을 설정하여 `kubectl`이 프록시를 거치도록 설정할 수 있다.
|
||||
다음과 같이 kubeconfig 파일에서 `proxy-url`를 사용하여 `kubectl`이 각 클러스터마다 프록시를 거치도록 설정할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
|
||||
proxy-url: https://proxy.host:3128
|
||||
|
||||
clusters:
|
||||
- cluster:
|
||||
proxy-url: http://proxy.example.org:3128
|
||||
server: https://k8s.example.org/k8s/clusters/c-xxyyzz
|
||||
name: development
|
||||
|
||||
users:
|
||||
|
|
@ -168,7 +168,6 @@ users:
|
|||
contexts:
|
||||
- context:
|
||||
name: development
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -247,6 +247,8 @@ API 크리덴셜이 [TokenRequest](/docs/reference/kubernetes-api/authentication
|
|||
예를 들어, 영원히 만료되지 않는 토큰이 필요한 경우에 활용할 수 있다.
|
||||
그러나, 이렇게 하기보다는 API 접근에 필요한 토큰을 얻기 위해
|
||||
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 서브리소스를 사용하는 것을 권장한다.
|
||||
`TokenRequest` API로부터 토큰을 얻기 위해
|
||||
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 특정 경로에 대한 시크릿 키 투영하기
|
||||
|
|
@ -887,14 +889,29 @@ empty-secret Opaque 0 2m6s
|
|||
|
||||
`kubernetes.io/service-account-token` 시크릿 타입은
|
||||
{{< glossary_tooltip text="서비스 어카운트" term_id="service-account" >}}를 확인하는
|
||||
토큰을 저장하기 위해서 사용한다.
|
||||
토큰 자격증명을 저장하기 위해서 사용한다.
|
||||
|
||||
1.22 버전 이후로는 이러한 타입의 시크릿은 더 이상 파드에 자격증명을 마운트하는 데 사용되지 않으며,
|
||||
서비스 어카운트 토큰 시크릿 오브젝트를 사용하는 대신
|
||||
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 통해 토큰을 얻는 것이 추천된다.
|
||||
`TokenRequest` API에서 얻은 토큰은 제한된 수명을 가지며 다른 API 클라이언트에서 읽을 수 없기 때문에
|
||||
시크릿 오브젝트에 저장된 토큰보다 더 안전하다.
|
||||
`TokenRequest` API에서 토큰을 얻기 위해서
|
||||
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
|
||||
|
||||
토큰을 얻기 위한 `TokenRequest` API를 사용할 수 없는 경우에는
|
||||
서비스 어카운트 토큰 시크릿 오브젝트를 생성할 수 밖에 없으나,
|
||||
이는 만료되지 않는 토큰 자격증명을 읽기 가능한 API 오브젝트로
|
||||
지속되는 보안 노출 상황을 감수할 수 있는 경우에만 생성해야 한다.
|
||||
|
||||
이 시크릿 타입을 사용할 때는,
|
||||
`kubernetes.io/service-account.name` 어노테이션이 존재하는
|
||||
서비스 어카운트 이름으로 설정되도록 해야 한다.
|
||||
쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
|
||||
서비스 어카운트 이름으로 설정되도록 해야 한다. 만약 서비스 어카운트와
|
||||
시크릿 오브젝트를 모두 생성하는 경우, 서비스 어카운트를 먼저 생성해야만 한다.
|
||||
|
||||
시크릿이 생성된 후, 쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
|
||||
`kubernetes.io/service-account.uid` 어노테이션 및
|
||||
`data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채우며,
|
||||
이들은 인증 토큰을 보관한다.
|
||||
인증 토큰을 보관하고 있는 `data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채운다.
|
||||
|
||||
다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다.
|
||||
|
||||
|
|
@ -911,17 +928,11 @@ data:
|
|||
extra: YmFyCg==
|
||||
```
|
||||
|
||||
`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을
|
||||
생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스
|
||||
어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다.
|
||||
|
||||
이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나
|
||||
기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만
|
||||
필요하다면, 이것이 권장되는 워크플로우이다.
|
||||
시크릿을 만든 후, 쿠버네티스가 `data` 필드에 `token` 키를 채울 때까지 기다린다.
|
||||
|
||||
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
|
||||
서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
|
||||
또한 파드에서 서비스 어카운트를 참조하는 방법을
|
||||
또한 파드에서 서비스 어카운트 자격증명을 참조하는 방법에 대한 정보는
|
||||
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
|
||||
`automountServiceAccountToken` 필드와 `serviceAccountName`
|
||||
필드를 통해 확인할 수 있다.
|
||||
|
|
@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \
|
|||
```
|
||||
|
||||
이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다.
|
||||
다음 명령으로 이 새 시크릿에서 `.data.dockercfgjson` 필드를 덤프하고
|
||||
다음 명령으로 이 새 시크릿에서 `.data.dockerconfigjson` 필드를 덤프하고
|
||||
base64로 디코드하면,
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
# - perithompson
|
||||
title: 윈도우 노드의 자원 관리
|
||||
content_type: concept
|
||||
weight: 75
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 리눅스와 윈도우 간에 리소스를 관리하는 방법의 차이점을 간략하게 설명한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
리눅스 노드에서, {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}이
|
||||
리소스 제어를 위한 파드 경계로서 사용된다.
|
||||
컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다.
|
||||
cpu/io/memory 통계를 수집하기 위해 cgroup API를 사용할 수 있다.
|
||||
|
||||
반대로, 윈도우는 시스템 네임스페이스 필터와 함께
|
||||
컨테이너별로 [잡(job) 오브젝트](https://docs.microsoft.com/windows/win32/procthread/job-objects)를 사용하여
|
||||
모든 프로세스를 컨테이너 안에 포함시키고 호스트와의 논리적 격리를 제공한다.
|
||||
(잡 오브젝트는 윈도우의 프로세스 격리 메커니즘이며
|
||||
쿠버네티스의 {{< glossary_tooltip term_id="job" text="잡(Job)" >}}과는 다른 것이다.)
|
||||
|
||||
네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다.
|
||||
이는 곧 시스템 권한은 호스트 입장에서 주장할(assert) 수 없고,
|
||||
이로 인해 특권을 가진(privileged) 컨테이너는 윈도우에서 사용할 수 없음을 의미한다.
|
||||
또한 보안 계정 매니저(Security Account Manager, SAM)가 분리되어 있으므로
|
||||
컨테이너는 호스트의 ID를 가정(assume)할 수 없다.
|
||||
|
||||
## 메모리 관리 {#resource-management-memory}
|
||||
|
||||
윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다.
|
||||
윈도우는 모든 사용자 모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일(pagefile)이 필수이다.
|
||||
|
||||
윈도우 노드는 프로세스를 위해 메모리를 오버커밋(overcommit)하지 않는다.
|
||||
이로 인해 윈도우는 메모리 컨디션에 도달하는 방식이 리눅스와 다르며,
|
||||
프로세스는 메모리 부족(OOM, out of memory) 종료를 겪는 대신 디스크에 페이징을 수행한다.
|
||||
메모리가 오버프로비저닝(over-provision)되고 전체 물리 메모리가 고갈되면,
|
||||
페이징으로 인해 성능이 저하될 수 있다.
|
||||
|
||||
## CPU 관리 {#resource-management-cpu}
|
||||
|
||||
윈도우는 각 프로세스에 할당되는 CPU 시간의 양을 제한할 수는 있지만,
|
||||
CPU 시간의 최소량을 보장하지는 않는다.
|
||||
|
||||
윈도우에서, kubelet은 kubelet 프로세스의
|
||||
[스케줄링 우선 순위](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities)를 설정하기 위한 명령줄 플래그인
|
||||
`--windows-priorityclass`를 지원한다.
|
||||
이 플래그를 사용하면 윈도우 호스트에서 실행되는 kubelet 프로세스가 다른 프로세스보다 더 많은 CPU 시간 슬라이스를 할당받는다.
|
||||
할당 가능한 값 및 각각의 의미에 대한 자세한 정보는
|
||||
[윈도우 프라이어리티 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다.
|
||||
실행 중인 파드가 kubelet의 CPU 사이클을 빼앗지 않도록 하려면, 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정한다.
|
||||
|
||||
## 리소스 예약 {#resource-reservation}
|
||||
|
||||
운영 체제, 컨테이너 런타임, 그리고 kubelet과 같은 쿠버네티스 호스트 프로세스가 사용하는 메모리 및 CPU를 고려하기 위해,
|
||||
kubelet 플래그 `--kube-reserved` 및 `--system-reserved`를 사용하여
|
||||
메모리 및 CPU 리소스의 예약이 가능하다 (그리고 필요하다).
|
||||
윈도우에서 이들 값은 노드의
|
||||
[할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스의 계산에만 사용된다.
|
||||
|
||||
{{< caution >}}
|
||||
워크로드를 배포할 때, 컨테이너에 메모리 및 CPU 리소스 제한을 걸자.
|
||||
이 또한 NodeAllocatable에서 차감되며, 클러스터 수준 스케줄러가 각 파드를 어떤 노드에 할당할지 결정하는 데 도움을 준다.
|
||||
|
||||
제한을 설정하지 않은 파드를 스케줄링하면 윈도우 노드가 오버프로비전될 수 있으며,
|
||||
극단적인 경우 노드가 비정상 상태(unhealthy)로 될 수도 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
윈도우에서는, 메모리를 최소 2GB 이상 예약하는 것이 좋다.
|
||||
|
||||
얼마나 많은 양의 CPU를 예약할지 결정하기 위해,
|
||||
각 노드의 최대 파드 수를 확인하고 해당 노드의 시스템 서비스의 CPU 사용량을 모니터링한 뒤,
|
||||
워크로드 요구사항을 충족하는 값을 선택한다.
|
||||
|
|
@ -17,14 +17,14 @@ no_list: true
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
|
||||
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
|
||||
거의 없다.
|
||||
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 쿠버네티스 프로젝트를
|
||||
포크하거나 코드에 패치를 제출할 필요가 거의 없다.
|
||||
|
||||
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
|
||||
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
|
||||
조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
|
||||
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
|
||||
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는
|
||||
쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
|
||||
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
|
||||
그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다.
|
||||
|
||||
|
|
@ -32,11 +32,14 @@ no_list: true
|
|||
|
||||
## 개요
|
||||
|
||||
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
|
||||
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만
|
||||
포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로
|
||||
나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
|
||||
|
||||
## 구성
|
||||
|
||||
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
|
||||
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에
|
||||
각 바이너리 별로 문서화되어 있다.
|
||||
|
||||
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
||||
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
|
|
@ -44,9 +47,22 @@ no_list: true
|
|||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
|
||||
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
|
||||
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서
|
||||
플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경
|
||||
가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후
|
||||
쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시
|
||||
시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
|
||||
|
||||
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
|
||||
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/),
|
||||
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/),
|
||||
[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및
|
||||
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은
|
||||
*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는
|
||||
일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은
|
||||
선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터
|
||||
구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인
|
||||
경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을
|
||||
사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
|
||||
|
||||
## 익스텐션
|
||||
|
||||
|
|
@ -70,10 +86,9 @@ no_list: true
|
|||
컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
|
||||
오브젝트의 `.status`를 업데이트 한다.
|
||||
|
||||
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
|
||||
원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
|
||||
*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
|
||||
추가한다.
|
||||
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때
|
||||
이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와
|
||||
마찬가지로 웹훅은 장애 지점을 추가한다.
|
||||
|
||||
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
|
||||
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
|
||||
|
|
@ -95,15 +110,35 @@ kubectl에서 사용한다.
|
|||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
||||
|
||||
|
||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
||||
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
|
||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
|
||||
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
|
||||
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
|
||||
7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
|
||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다.
|
||||
[Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다.
|
||||
개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
||||
|
||||
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
|
||||
1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나,
|
||||
콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은
|
||||
[API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
|
||||
|
||||
1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는
|
||||
쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를
|
||||
추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로
|
||||
*커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다.
|
||||
커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||
|
||||
1. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지
|
||||
방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
|
||||
|
||||
1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로
|
||||
구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
|
||||
|
||||
1. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼
|
||||
보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한
|
||||
파드 네트워킹 구현이 가능하다.
|
||||
|
||||
1. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는
|
||||
[스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
|
||||
|
||||
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는
|
||||
여러 유형의 익스텐션이 포함될 수 있다.
|
||||
|
||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
||||
|
||||
|
|
@ -112,60 +147,86 @@ kubectl에서 사용한다.
|
|||
|
||||
### 사용자 정의 유형
|
||||
|
||||
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
|
||||
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고
|
||||
`kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면
|
||||
쿠버네티스에 커스텀 리소스를 추가하자.
|
||||
|
||||
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
|
||||
|
||||
커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
|
||||
커스텀 리소스에 대한 자세한 내용은
|
||||
[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
|
||||
|
||||
|
||||
### 새로운 API와 자동화의 결합
|
||||
|
||||
사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
|
||||
사용자 정의 리소스 API와 컨트롤 루프의 조합을
|
||||
[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은
|
||||
특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한
|
||||
사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
|
||||
|
||||
### 빌트인 리소스 변경
|
||||
|
||||
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
|
||||
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
|
||||
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상
|
||||
새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
|
||||
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API
|
||||
접근 익스텐션은 영향을 준다.
|
||||
|
||||
|
||||
### API 접근 익스텐션
|
||||
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
|
||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후
|
||||
다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에
|
||||
대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를
|
||||
참고하길 바란다.
|
||||
|
||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
||||
|
||||
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
|
||||
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에
|
||||
있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여
|
||||
확인할 수 있다(웹훅). 이러한 방법은 모두
|
||||
[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
|
||||
|
||||
### 인증
|
||||
|
||||
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
|
||||
|
||||
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
|
||||
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를
|
||||
요청하는 클라이언트의 사용자 이름에 매핑한다.
|
||||
|
||||
쿠버네티스는 몇 가지 빌트인 인증 방법과
|
||||
필요에 맞지 않는 경우
|
||||
[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
|
||||
|
||||
### 인가
|
||||
|
||||
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
|
||||
|
||||
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정
|
||||
사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서
|
||||
작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인
|
||||
인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을
|
||||
통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
|
||||
|
||||
### 동적 어드미션 컨트롤
|
||||
|
||||
요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
|
||||
요청이 승인된 후, 쓰기 작업인 경우
|
||||
[어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다.
|
||||
빌트인 단계 외에도 몇 가지 익스텐션이 있다.
|
||||
|
||||
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
|
||||
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
|
||||
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은
|
||||
컨테이너에서 실행할 수 있는 이미지를 제한한다.
|
||||
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인
|
||||
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을
|
||||
사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
|
||||
|
||||
## 인프라스트럭처 익스텐션
|
||||
|
||||
### 스토리지 플러그인
|
||||
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
|
||||
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
|
||||
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
|
||||
|
||||
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다.
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을
|
||||
사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이
|
||||
볼륨 유형을 마운트 할 수 있다.
|
||||
|
||||
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때
|
||||
추천하는 방식이다. 자세한 정보는
|
||||
[스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서
|
||||
찾을 수 있다.
|
||||
|
||||
### 장치 플러그인
|
||||
|
||||
|
|
@ -173,7 +234,6 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
|
|||
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
|
||||
발견할 수 있게 해준다.
|
||||
|
||||
|
||||
### 네트워크 플러그인
|
||||
|
||||
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
|
|
@ -192,7 +252,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
|
|||
|
||||
스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
|
||||
파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
|
||||
[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
|
||||
[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을
|
||||
지원한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 20
|
|||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는
|
||||
[장치 플러그인 프레임워크](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)를
|
||||
[장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를
|
||||
제공한다.
|
||||
|
||||
공급 업체는 쿠버네티스 자체의 코드를 커스터마이징하는 대신, 수동 또는
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ weight: 10
|
|||
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
|
||||
클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
|
||||
|
||||
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
|
||||
|
||||
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의
|
||||
CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다.
|
||||
쿠버네티스 플러그인은
|
||||
|
|
@ -24,26 +26,37 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
|
|||
|
||||
## 설치
|
||||
|
||||
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
|
||||
네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
|
||||
|
||||
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
|
||||
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
|
||||
{{< note >}}
|
||||
쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
|
||||
이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다.
|
||||
|
||||
dockershim 제거 후 문제가 발생하는 경우
|
||||
[CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자.
|
||||
{{< /note >}}
|
||||
|
||||
컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자.
|
||||
- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
|
||||
- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
|
||||
|
||||
CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다.
|
||||
|
||||
## 네트워크 플러그인 요구 사항
|
||||
|
||||
파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
|
||||
쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
|
||||
iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다.
|
||||
예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
|
||||
플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
|
||||
|
||||
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
|
||||
|
||||
### CNI
|
||||
### 루프백 CNI
|
||||
|
||||
CNI 플러그인은 Kubelet에 `--network-plugin=cni` 커맨드라인 옵션을 전달하여 선택된다. Kubelet은 `--cni-conf-dir`(기본값은 `/etc/cni/net.d`)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 파드의 네트워크를 설정한다. CNI 구성 파일은 [CNI 명세](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)와 일치해야 하며, 구성에서 참조하는 필수 CNI 플러그인은 `--cni-bin-dir`(기본값은 `/opt/cni/bin`)에 있어야 한다.
|
||||
쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다.
|
||||
루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91))
|
||||
|
||||
디렉터리에 여러 CNI 구성 파일이 있는 경우, kubelet은 이름별 알파벳 순으로 구성 파일을 사용한다.
|
||||
|
||||
구성 파일에 지정된 CNI 플러그인 외에도, 쿠버네티스는 최소 0.2.0 버전의 표준 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 플러그인이 필요하다.
|
||||
|
||||
#### hostPort 지원
|
||||
### hostPort 지원
|
||||
|
||||
CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
|
||||
플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다.
|
||||
|
|
@ -80,7 +93,7 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
|
|||
}
|
||||
```
|
||||
|
||||
#### 트래픽 셰이핑 지원
|
||||
### 트래픽 셰이핑(shaping) 지원
|
||||
|
||||
**실험적인 기능입니다**
|
||||
|
||||
|
|
@ -132,8 +145,4 @@ metadata:
|
|||
...
|
||||
```
|
||||
|
||||
## 용법 요약
|
||||
|
||||
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -111,7 +111,9 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
|||
{{% thirdparty-content %}}
|
||||
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
|
||||
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
|
||||
* [kube-rs](https://kube.rs/) (Rust)
|
||||
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
|
||||
* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
|
||||
|
|
|
|||
|
|
@ -1,232 +0,0 @@
|
|||
---
|
||||
title: 서비스 카탈로그
|
||||
|
||||
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
|
||||
|
||||
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다.
|
||||
매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다.
|
||||
|
||||
{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## 유스케이스 예제
|
||||
|
||||
한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다.
|
||||
그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다.
|
||||
다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다.
|
||||
|
||||
클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
|
||||
따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
|
||||
애플리케이션은 메시지 큐에 서비스로 접속할 수 있다.
|
||||
|
||||
## 아키텍처
|
||||
|
||||
서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
|
||||
|
||||
이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
|
||||
|
||||
### API 리소스
|
||||
|
||||
서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다.
|
||||
|
||||
* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표.
|
||||
이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다.
|
||||
* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스.
|
||||
새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다.
|
||||
* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다.
|
||||
* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스.
|
||||
클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다.
|
||||
새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다.
|
||||
* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다.
|
||||
자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다.
|
||||
서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다.
|
||||
|
||||
### 인증
|
||||
|
||||
서비스 카탈로그는 다음의 인증 방법을 지원한다.
|
||||
|
||||
* 기본 (username/password)
|
||||
* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
|
||||
|
||||
## 사용법
|
||||
|
||||
클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다.
|
||||
|
||||
1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열.
|
||||
1. 매니지드 서비스의 새 인스턴스 프로비저닝.
|
||||
1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩.
|
||||
1. 연결 자격 증명을 애플리케이션에 매핑.
|
||||
|
||||
### 매니지드 서비스와 서비스 플랜 나열
|
||||
|
||||
먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다.
|
||||
|
||||
다음은 `ClusterServiceBroker` 리소스 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: servicecatalog.k8s.io/v1beta1
|
||||
kind: ClusterServiceBroker
|
||||
metadata:
|
||||
name: cloud-broker
|
||||
spec:
|
||||
# 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.)
|
||||
url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
|
||||
#####
|
||||
# bearer 토큰 정보 혹은 TLS용 caBundle과 같은
|
||||
# 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.
|
||||
#####
|
||||
```
|
||||
|
||||
다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
|
||||
|
||||
|
||||
|
||||
1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다.
|
||||
1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다.
|
||||
1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다.
|
||||
|
||||
kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
|
||||
|
||||
아래와 같은 형태의 서비스 이름 목록이 출력된다.
|
||||
|
||||
SERVICE NAME EXTERNAL NAME
|
||||
4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
|
||||
... ...
|
||||
|
||||
또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다.
|
||||
|
||||
kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
|
||||
|
||||
아래와 같은 형태의 플랜 이름 목록이 출력된다.
|
||||
|
||||
PLAN NAME EXTERNAL NAME
|
||||
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
|
||||
... ...
|
||||
|
||||
|
||||
### 새 인스턴스 프로비저닝
|
||||
|
||||
클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다.
|
||||
|
||||
다음은 `ServiceInstance` 리소스의 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: servicecatalog.k8s.io/v1beta1
|
||||
kind: ServiceInstance
|
||||
metadata:
|
||||
name: cloud-queue-instance
|
||||
namespace: cloud-apps
|
||||
spec:
|
||||
# 이전에 반환된 서비스 중 하나를 참조
|
||||
clusterServiceClassExternalName: cloud-provider-service
|
||||
clusterServicePlanExternalName: service-plan-name
|
||||
#####
|
||||
# 이곳에 서비스 브로커가 사용할 수 있는
|
||||
# 파라미터를 추가할 수 있다.
|
||||
#####
|
||||
```
|
||||
|
||||
다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
|
||||
|
||||
|
||||
|
||||
1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다.
|
||||
1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다.
|
||||
1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다.
|
||||
|
||||
### 매니지드 서비스에 바인딩
|
||||
|
||||
새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다.
|
||||
|
||||
다음은 `ServiceBinding` 리소스의 예시다.
|
||||
|
||||
```yaml
|
||||
apiVersion: servicecatalog.k8s.io/v1beta1
|
||||
kind: ServiceBinding
|
||||
metadata:
|
||||
name: cloud-queue-binding
|
||||
namespace: cloud-apps
|
||||
spec:
|
||||
instanceRef:
|
||||
name: cloud-queue-instance
|
||||
#####
|
||||
# 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의
|
||||
# 추가 정보를 여기에 추가할 수 있다.
|
||||
#####
|
||||
```
|
||||
|
||||
다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
|
||||
|
||||
|
||||
|
||||
1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
|
||||
1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
|
||||
1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
|
||||
|
||||
### 연결 자격 증명 매핑
|
||||
|
||||
바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
|
||||
이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
|
||||
#### 파드 구성 파일
|
||||
|
||||
이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
|
||||
|
||||
다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다.
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
volumes:
|
||||
- name: provider-cloud-key
|
||||
secret:
|
||||
secretName: sa-key
|
||||
containers:
|
||||
...
|
||||
volumeMounts:
|
||||
- name: provider-cloud-key
|
||||
mountPath: /var/secrets/provider
|
||||
env:
|
||||
- name: PROVIDER_APPLICATION_CREDENTIALS
|
||||
value: "/var/secrets/provider/key.json"
|
||||
```
|
||||
|
||||
다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다.
|
||||
|
||||
|
||||
```yaml
|
||||
...
|
||||
env:
|
||||
- name: "TOPIC"
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: provider-queue-credentials
|
||||
key: topic
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
|
||||
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
|
||||
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
|
||||
|
|
@ -76,7 +76,7 @@ card:
|
|||
|
||||
쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
|
||||
Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
|
||||
자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
|
||||
자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) 디자인 제안과
|
||||
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
|
||||
IDL(인터페이스 정의 언어) 파일을 참고한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -100,4 +100,4 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
|
||||
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
|
||||
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다.
|
||||
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다.
|
||||
|
||||
제한의 사용에 대한 예시는 다음을 참조한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - derekwaynecarr
|
||||
title: 리소스 쿼터
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -22,8 +22,7 @@ weight: 20
|
|||
|
||||
리소스 쿼터는 다음과 같이 작동한다.
|
||||
|
||||
- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을
|
||||
적용하기 위한 지원이 계획되어 있다.
|
||||
- 다른 팀은 다른 네임스페이스에서 작업한다. 이것은 [RBAC](/docs/reference/access-authn-authz/rbac/)으로 설정할 수 있다.
|
||||
|
||||
- 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다.
|
||||
|
||||
|
|
@ -698,7 +697,7 @@ resourcequota/pods-cluster-services created
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다.
|
||||
- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)를 참고한다.
|
||||
- [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다.
|
||||
- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다.
|
||||
- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)를 읽는다.
|
||||
- [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -124,8 +124,8 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
|
|||
|
||||
이 예시에서는 다음의 규칙이 적용된다.
|
||||
|
||||
* 노드는 키가 `kubernetes.io/os`이고 값이 `linux`인 레이블을
|
||||
갖고 *있어야 한다* .
|
||||
* 노드는 키가 `topology.kubernetes.io/zone`인 레이블을 갖고 *있어야 하며*,
|
||||
레이블의 값이 `antarctica-east1` 혹은 `antarctica-west1`*여야 한다*.
|
||||
* 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을
|
||||
갖고 있는 노드를 *선호한다* .
|
||||
|
||||
|
|
@ -302,9 +302,8 @@ Y는 쿠버네티스가 충족할 규칙이다.
|
|||
다른 노드도 존재한다면,
|
||||
스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다.
|
||||
|
||||
[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에서
|
||||
파드 어피니티와 안티-어피니티에 대한
|
||||
많은 예시를 볼 수 있다.
|
||||
파드 어피니티와 안티-어피니티의 예시에 대해 익숙해지고 싶다면,
|
||||
[디자인 제안](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)을 참조한다.
|
||||
|
||||
파드 어피니티와 안티-어피니티의 `operator` 필드에
|
||||
`In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다.
|
||||
|
|
@ -472,9 +471,11 @@ spec:
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다.
|
||||
* [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와
|
||||
[파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다.
|
||||
* [노드 어피니티](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)와
|
||||
[파드간 어피니티/안티-어피니티](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다.
|
||||
* [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)가
|
||||
노드 수준 리소스 할당 결정에 어떻게 관여하는지 알아본다.
|
||||
* [노드셀렉터(nodeSelector)](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 어떻게 사용하는지 알아본다.
|
||||
* [어피니티/안티-어피니티](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)를 어떻게 사용하는지 알아본다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
|
|||
map[cpu:250m memory:120Mi]
|
||||
```
|
||||
|
||||
만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
|
||||
만약 [리소스쿼터](/ko/docs/concepts/policy/resource-quotas/) 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는
|
||||
`overhead` 필드도 추가된다.
|
||||
|
||||
kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와
|
||||
|
|
@ -196,3 +196,4 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
|
|||
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다.
|
||||
* 더 자세한 문맥은
|
||||
[파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,72 +1,102 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
|
||||
# reviewers:
|
||||
# - bsalamat
|
||||
# - k82cn
|
||||
# - ahg-g
|
||||
title: 리소스 빈 패킹(bin packing)
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation`
|
||||
우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록
|
||||
구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
|
||||
kube-scheduler를 미세 조정할 수 있다.
|
||||
kube-scheduler의 [스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins) `NodeResourcesFit`에는,
|
||||
리소스의 빈 패킹(bin packing)을 지원하는 `MostAllocated`과 `RequestedToCapacityRatio`라는 두 가지 점수 산정(scoring) 전략이 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
|
||||
## MostAllocated 전략을 사용하여 빈 패킹 활성화하기
|
||||
`MostAllocated` 전략은 리소스 사용량을 기반으로 할당량이 많은 노드를 높게 평가하여 노드에 점수를 매긴다.
|
||||
각 리소스 유형별로 가중치를 설정하여 노드 점수에 미치는 영향을 조정할 수 있다.
|
||||
|
||||
쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
|
||||
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다.
|
||||
이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
|
||||
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
|
||||
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은
|
||||
`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다.
|
||||
이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다.
|
||||
`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로
|
||||
최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다.
|
||||
`NodeResourcesFit` 플러그인에 대한 `MostAllocated` 전략을 설정하려면,
|
||||
다음과 유사한 [스케줄러 설정](/ko/docs/reference/scheduling/config)을 사용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- pluginConfig:
|
||||
- args:
|
||||
scoringStrategy:
|
||||
resources:
|
||||
- name: cpu
|
||||
weight: 1
|
||||
- name: memory
|
||||
weight: 1
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 3
|
||||
type: MostAllocated
|
||||
name: NodeResourcesFit
|
||||
```
|
||||
|
||||
기타 파라미터와 기본 구성에 대한 자세한 내용은
|
||||
[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다.
|
||||
|
||||
## RequestedToCapacityRatio을 사용하여 빈 패킹 활성화하기
|
||||
|
||||
`RequestedToCapacityRatio` 전략은 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
|
||||
용량 대비 요청 비율을 기반으로 노드의 점수를 매길 수 있게 한다.
|
||||
이를 통해 사용자는 적절한 파라미터를 사용하여 확장된 리소스를 빈 팩으로 만들 수 있어
|
||||
대규모의 클러스터에서 부족한 리소스의 활용도를 향상시킬 수 있다. 이 전략은
|
||||
할당된 리소스의 구성된 기능에 따라 노드를 선호하게 한다. `NodeResourcesFit`점수 기능의
|
||||
`RequestedToCapacityRatio` 동작은 [scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy)필드를
|
||||
이용하여 제어할 수 있다.
|
||||
`scoringStrategy` 필드에서 `requestedToCapacityRatioParam`와 `resources`라는 두 개의 파라미터를
|
||||
구성할 수 있다. `requestedToCapacityRatioParam`파라미터의
|
||||
`shape`를 사용하면 `utilization`과 `score` 값을 기반으로
|
||||
최소 요청 혹은 최대 요청된 대로 기능을 조정할 수 있게 한다.
|
||||
`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과
|
||||
각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
|
||||
|
||||
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
|
||||
`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
|
||||
다음은 `requestedToCapacityRatio` 를 이용해
|
||||
확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 빈 패킹 동작을
|
||||
설정하는 구성의 예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
# ...
|
||||
pluginConfig:
|
||||
- name: RequestedToCapacityRatio
|
||||
args:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 10
|
||||
- utilization: 100
|
||||
score: 0
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 5
|
||||
- pluginConfig:
|
||||
- args:
|
||||
scoringStrategy:
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 3
|
||||
requestedToCapacityRatioParam:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
- utilization: 100
|
||||
score: 10
|
||||
type: RequestedToCapacityRatio
|
||||
name: NodeResourcesFit
|
||||
```
|
||||
|
||||
kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여
|
||||
`KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에
|
||||
전달된다.
|
||||
|
||||
**이 기능은 기본적으로 비활성화되어 있다.**
|
||||
기타 파라미터와 기본 구성에 대한 자세한 내용은
|
||||
[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다.
|
||||
|
||||
### 우선 순위 기능 튜닝하기
|
||||
### 점수 기능 튜닝하기
|
||||
|
||||
`shape` 는 `RequestedToCapacityRatioPriority` 기능의
|
||||
동작을 지정하는 데 사용된다.
|
||||
`shape` 는 `RequestedToCapacityRatio` 기능의 동작을 지정하는 데 사용된다.
|
||||
|
||||
```yaml
|
||||
shape:
|
||||
|
|
@ -221,3 +251,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
|||
|
||||
- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다.
|
||||
- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - davidopp
|
||||
# - kevin-wangzefeng
|
||||
# - bsalamat
|
||||
title: 테인트(Taints)와 톨러레이션(Tolerations)
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -15,8 +15,7 @@ weight: 40
|
|||
(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다.
|
||||
_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다.
|
||||
|
||||
_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에
|
||||
스케줄되게 하지만 필수는 아니다.
|
||||
_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 [다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다.
|
||||
|
||||
테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
|
||||
않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
title: 쿠버네티스 API 접근 제어하기
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -164,7 +165,27 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수
|
|||
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
|
||||
- 인증 및 인가 모듈을 실행한다.
|
||||
|
||||
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
|
||||
API 서버는 포트 443에서 서비스한다.
|
||||
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
|
||||
이외에 클러스터 설정 방법은 다양하다.
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
|
||||
|
||||
- [인증하기](/docs/reference/access-authn-authz/authentication/)
|
||||
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/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/)
|
||||
- [역할 기반 접근 제어(role based access control)](/docs/reference/access-authn-authz/rbac/)
|
||||
- [속성 기반 접근 제어(attribute based access control)](/docs/reference/access-authn-authz/abac/)
|
||||
- [노드 인가](/docs/reference/access-authn-authz/node/)
|
||||
- [웹훅(webhook) 인가](/docs/reference/access-authn-authz/webhook/)
|
||||
- [인증서 서명 요청(Certificate Signing Request)](/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
- [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 및
|
||||
[인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 포함하기
|
||||
- 서비스 어카운트
|
||||
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
- [운영](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
|
||||
또한, 다음 사항을 익힐 수 있다.
|
||||
- 파드가 API 크리덴셜(credential)을 얻기 위해
|
||||
[시크릿(Secret)](/ko/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
|
||||
을 사용하는 방법.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
# - perithompson
|
||||
title: 윈도우 노드에서의 보안
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지에서는 윈도우 운영 체제에서의 보안 고려 사항 및 추천 사례에 대해 기술한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 노드의 시크릿 데이터 보호
|
||||
|
||||
윈도우에서, 시크릿에 있던 데이터는 노드의 로컬 스토리지에
|
||||
평문으로 기록된다(리눅스는 tmpfs 또는 인메모리 파일시스템에 기록).
|
||||
클러스터 운영자로서, 다음 2 가지의 추가 사항을 고려해야 한다.
|
||||
|
||||
1. 파일 ACL을 사용하여 시크릿의 파일 위치를 보호한다.
|
||||
1. [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용하여 볼륨 수준의 암호화를 적용한다.
|
||||
|
||||
## 컨테이너 사용자
|
||||
|
||||
윈도우 파드 또는 컨테이너에
|
||||
[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 설정하여
|
||||
해당 컨테이너 프로세스를 실행할 사용자를 지정할 수 있다.
|
||||
이는 [RunAsUser](/ko/docs/concepts/security/pod-security-policy/#사용자-및-그룹)와 대략적으로 동등하다.
|
||||
|
||||
윈도우 컨테이너는 ContainerUser와 ContainerAdministrator의 2 개의 기본 사용자 계정을 제공한다.
|
||||
이 두 사용자 계정이 어떻게 다른지는 마이크로소프트의 _안전한 윈도우 컨테이너_ 문서 내의
|
||||
[언제 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`로 실행된다
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
[그룹 관리 서비스 어카운트](/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)를 사용할 수 있다.
|
||||
|
|
@ -7,26 +7,25 @@ description: >
|
|||
|
||||
## 쿠버네티스 네트워크 모델
|
||||
|
||||
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
|
||||
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
|
||||
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
|
||||
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를
|
||||
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고
|
||||
하위 호환성을 갖는 모델이 제시된다.
|
||||
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
|
||||
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다.
|
||||
(이를 통해, 의도적인 네트워크 분할 정책을 방지)
|
||||
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
|
||||
파드와 통신할 수 있다
|
||||
* 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와
|
||||
통신할 수 있다.
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
|
||||
파드와 통신할 수 있다.
|
||||
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
|
||||
다음의 요구사항도 존재한다.
|
||||
|
||||
* 한 노드의 호스트 네트워크에 있는 파드는
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예:
|
||||
리눅스)에 대해서는, 파드가 노드의 호스트 네트워크에 연결되어 있을 때에도 파드는 여전히
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
|
||||
|
||||
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
|
||||
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - davidopp
|
||||
# - thockin
|
||||
title: 서비스 및 파드용 DNS
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -226,6 +226,7 @@ DNS 정책은 파드별로 설정할 수 있다.
|
|||
확인할 수 있다.
|
||||
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
|
||||
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
|
||||
- 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다.
|
||||
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
|
||||
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
|
||||
아래 절인 [파드의 DNS 설정](#pod-dns-config)에서
|
||||
|
|
@ -306,7 +307,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같
|
|||
kubectl exec -it dns-example -- cat /etc/resolv.conf
|
||||
```
|
||||
출력은 다음과 같은 형식일 것이다.
|
||||
```shell
|
||||
```
|
||||
nameserver fd00:79:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
options ndots:5
|
||||
|
|
@ -323,6 +324,24 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
|
|||
쿠버네티스는 최대 32개의 탐색 도메인과
|
||||
최대 2048자의 탐색 도메인 목록을 허용한다.
|
||||
|
||||
## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows}
|
||||
|
||||
- ClusterFirstWithHostNet은 윈도우 노드에서 구동 중인 파드에는 지원되지 않는다.
|
||||
윈도우는 `.`를 포함한 모든 네임(주소)을 FQDN으로 취급하여 FQDN 해석을 생략한다.
|
||||
- 윈도우에는 여러 DNS 해석기가 사용될 수 있다. 이러한 해석기는
|
||||
각자 조금씩 다르게 동작하므로, 네임 쿼리 해석을 위해서
|
||||
[`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
|
||||
파워쉘(powershell) cmdlet을 사용하는 것을 추천한다.
|
||||
- 리눅스에는 DNS 접미사 목록이 있는데, 이는 네임이 완전한 주소가 아니어서 주소
|
||||
해석에 실패한 경우 사용한다.
|
||||
윈도우에서는 파드의 네임스페이스(예: `mydns.svc.cluster.local`)와 연계된
|
||||
하나의 DNS 접미사만 가질 수 있다. 윈도우는 이러한 단일 접미사 통해 해석될 수 있는
|
||||
FQDNs, 서비스, 또는 네트워크 네임을 해석할 수 있다. 예를 들어, `default`에
|
||||
소속된 파드는 DNS 접미사 `default.svc.cluster.local`를 가진다.
|
||||
윈도우 파드 내부에서는 `kubernetes.default.svc.cluster.local`와
|
||||
`kubernetes`를 모두 해석할 수 있다. 그러나, 일부에만 해당(partially qualified)하는 네임(`kubernetes.default` 또는
|
||||
`kubernetes.default.svc`)은 해석할 수 없다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,15 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: IPv4/IPv6 이중 스택
|
||||
feature:
|
||||
title: IPv4/IPv6 이중 스택
|
||||
description: >
|
||||
파드와 서비스에 IPv4와 IPv6 주소 할당
|
||||
|
||||
content_type: concept
|
||||
# reviewers:
|
||||
# - lachie83
|
||||
# - khenidak
|
||||
# - aramase
|
||||
# - bridgetkromhout
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
|
@ -18,11 +17,11 @@ weight: 70
|
|||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
|
||||
|
||||
IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로
|
||||
활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -38,60 +37,70 @@ IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터
|
|||
|
||||
IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.
|
||||
|
||||
* 쿠버네티스 1.20 이상
|
||||
이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
|
||||
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
|
||||
문서 참조
|
||||
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
|
||||
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
* 쿠버네티스 1.20 및 이후 버전
|
||||
|
||||
예전 버전 쿠버네티스에서 이중 스택 서비스를 사용하는
|
||||
방법에 대한 정보는 해당 버전의 쿠버네티스에 대한
|
||||
문서를 참조한다.
|
||||
|
||||
* 이중 스택 네트워킹을 위한 공급자의 지원. (클라우드 공급자 또는 다른 방식으로
|
||||
쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 함.)
|
||||
* 이중 스택 네트워킹을 지원하는
|
||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
|
||||
|
||||
## IPv4/IPv6 이중 스택 구성
|
||||
|
||||
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
|
||||
|
||||
* kube-apiserver:
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kube-controller-manager:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면
|
||||
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해
|
||||
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
* kube-apiserver:
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kube-controller-manager:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면 관리자는 해당 노드에 듀얼 스택
|
||||
`.status.addresses`를 수동으로 설정하기 위해 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
|
||||
{{< note >}}
|
||||
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
|
||||
|
||||
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)
|
||||
|
||||
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한
|
||||
주소는 아니다. [RFC 4193](https://tools.ietf.org/html/rfc4193)을 확인한다.)
|
||||
{{< /note >}}
|
||||
|
||||
## 서비스
|
||||
|
||||
IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다.
|
||||
|
||||
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
|
||||
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다.
|
||||
(`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
|
||||
|
||||
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
|
||||
다음 값 중 하나로 설정한다.
|
||||
|
||||
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
|
||||
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스
|
||||
클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
|
||||
* `PreferDualStack`:
|
||||
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
|
||||
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
|
||||
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
|
||||
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로
|
||||
`.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
|
||||
|
||||
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
|
||||
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의
|
||||
순서를 정의하려는 경우, 서비스에서 옵션 필드
|
||||
`.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다.
|
||||
`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를
|
||||
재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면
|
||||
서비스를 삭제하고 다시 생성한다.
|
||||
{{< /note >}}
|
||||
|
||||
`.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다.
|
||||
|
|
@ -109,139 +118,196 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
|
|||
|
||||
#### 새로운 서비스에 대한 이중 스택 옵션
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.)
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다.
|
||||
이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서
|
||||
서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를
|
||||
`SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와
|
||||
같은 방식으로 동작한다.)
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다.
|
||||
1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을
|
||||
명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는
|
||||
서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의
|
||||
`.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는
|
||||
기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이
|
||||
`.spec.ClusterIPs`에서 계산된 보조 필드이다.
|
||||
|
||||
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
|
||||
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다.
|
||||
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다.
|
||||
* `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP
|
||||
범위와 동일한 주소 계열의 IP 주소를 기록한다.
|
||||
* 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는
|
||||
모두 하나의 주소만 나열한다.
|
||||
* 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을
|
||||
지정하면 `PreferDualStack`과 동일하게 작동한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
|
||||
|
||||
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
|
||||
1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고
|
||||
`.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에
|
||||
IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의
|
||||
첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
|
||||
|
||||
#### 기존 서비스의 이중 스택 기본값
|
||||
|
||||
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.)
|
||||
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된
|
||||
경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면
|
||||
이중 스택이 활성화된다.)
|
||||
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이
|
||||
`.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고
|
||||
`.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다.
|
||||
기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: 10.0.197.123
|
||||
clusterIPs:
|
||||
- 10.0.197.123
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
type: ClusterIP
|
||||
status:
|
||||
loadBalancer: {}
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: 10.0.197.123
|
||||
clusterIPs:
|
||||
- 10.0.197.123
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
type: ClusterIP
|
||||
status:
|
||||
loadBalancer: {}
|
||||
```
|
||||
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
|
||||
1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존
|
||||
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는
|
||||
`.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을
|
||||
`SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스
|
||||
클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로
|
||||
지정한다.
|
||||
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
|
||||
|
||||
kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
```shell
|
||||
kubectl get svc my-service -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: None
|
||||
clusterIPs:
|
||||
- None
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: MyApp
|
||||
name: my-service
|
||||
spec:
|
||||
clusterIP: None
|
||||
clusterIPs:
|
||||
- None
|
||||
ipFamilies:
|
||||
- IPv4
|
||||
ipFamilyPolicy: SingleStack
|
||||
ports:
|
||||
- port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: MyApp
|
||||
```
|
||||
|
||||
#### 단일 스택과 이중 스택 간 서비스 전환
|
||||
|
||||
서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다.
|
||||
|
||||
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
|
||||
1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를
|
||||
`SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다.
|
||||
이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의
|
||||
것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖는다.
|
||||
|
||||
`.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다.
|
||||
|
||||
이전:
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: SingleStack
|
||||
```
|
||||
이후:
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: PreferDualStack
|
||||
```
|
||||
이전:
|
||||
|
||||
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: SingleStack
|
||||
```
|
||||
|
||||
이후:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
ipFamilyPolicy: PreferDualStack
|
||||
```
|
||||
|
||||
1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를
|
||||
`PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다.
|
||||
이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs`
|
||||
배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고
|
||||
`.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
|
||||
|
||||
### 셀렉터가 없는 헤드리스 서비스
|
||||
|
||||
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다.
|
||||
[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가
|
||||
명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은
|
||||
`RequireDualStack` 이다.
|
||||
|
||||
### 로드밸런서 서비스 유형
|
||||
|
||||
서비스에 이중 스택 로드밸런서를 프로비저닝하려면
|
||||
* `.spec.type` 필드를 `LoadBalancer`로 설정
|
||||
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
|
||||
|
||||
* `.spec.type` 필드를 `LoadBalancer`로 설정
|
||||
* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
|
||||
|
||||
{{< note >}}
|
||||
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
|
||||
이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가
|
||||
IPv4 및 IPv6로드 밸런서를 지원해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 이그레스(Egress) 트래픽
|
||||
|
||||
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
|
||||
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상
|
||||
(예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는
|
||||
IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다.
|
||||
[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)
|
||||
프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
|
||||
|
||||
{{< note >}}
|
||||
{{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 윈도우 지원
|
||||
|
||||
윈도우에 있는 쿠버네티스는 싱글 스택(single-stack) "IPv6-only" 네트워킹을 지원하지 않는다. 그러나, 싱글 패밀리(single-family)
|
||||
서비스로 되어 있는 파드와 노드에 대해서는 듀얼 스택(dual-stack) IPv4/IPv6 네트워킹을
|
||||
지원한다.
|
||||
|
||||
`l2bridge` 네트워크로 IPv4/IPv6 듀얼 스택 네트워킹을 사용할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
윈도우에서 오버레이 (VXLAN) 네트워크은 듀얼 스택 네트워킹을 **지원하지 않는다.**
|
||||
{{< /note >}}
|
||||
|
||||
윈도우의 다른 네트워크 모델에 대한 내용은
|
||||
[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
|
||||
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화
|
||||
](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
|
||||
* [kubeadm을 사용하여 이중 스택 네트워킹 활성화](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
|
||||
|
|
|
|||
|
|
@ -46,6 +46,7 @@ weight: 40
|
|||
기반 인그레스 컨트롤러다.
|
||||
* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
|
||||
구동하는 인그레스 컨트롤러다.
|
||||
* [Kusk 게이트웨이](https://kusk.kubeshop.io/)는 OpenAPI 중심의 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
|
||||
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
|
||||
웹서버(프록시로 사용)와 함께 작동한다.
|
||||
* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - bprashanth
|
||||
title: 인그레스(Ingress)
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -30,23 +30,8 @@ weight: 40
|
|||
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
|
||||
|
||||
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스];
|
||||
ingress-->|라우팅 규칙|service[서비스];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service-->pod1[파드];
|
||||
service-->pod2[파드];
|
||||
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 ingress,service,pod1,pod2 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
|
||||
{{< figure src="/ko/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="그림. 인그레스" link="https://mermaid.live/edit#pako:eNqNksFK7DAUhl8lZDYKrYzjVSQjs9KdK11OZ5E2p06w05Yk1XtR4QojiM5OuHBlBhUENy5mIVjBJzLtO5ja6kxx4yY55PznO39OcoS9iAEmeE_QuI-2d9pOiJAXcAjVQjc_fdKT12zylP1L84u0t2gvoWySvj2n-vY8u7i39cO9vjzPHv7qqzHacEUH6btxEetpqm-m2XCMluwOD_cESNmdL-19NKoytt05LhpdT_PRGXp7Hmcv_48liAPuQddA9Mvwq0Qmbum1MHfzaM7z4XSOVYrKWsONI7bczUcjY6r3PdWqpSBk5e2plJvgozigPEQ-DwLSYIxZUoloH0jD9_0qtg85U33yK_5teVEQCdJoNpvtGmR_XVaIldaaB6s_ophcneIFiVQgKtKslDRc161jWjNM2XFG-pyRVQ3BKqZTLK3C5pyu_ADlAGrHpYtqb2MLD0AMKGfmBx0VOgerPgzAwcSEDHyaBMrBTnhipEnMqIItxlUkMPFpIMHCNFHR7p_Qw0SJBD5Fm5yaRx5UqpN3zjkTIA" >}}
|
||||
|
||||
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
|
||||
|
||||
|
|
@ -398,25 +383,8 @@ test-ingress external-lb * 203.0.113.123 80 59s
|
|||
트래픽을 라우팅 한다. 인그레스를 사용하면 로드 밸런서의 수를
|
||||
최소로 유지할 수 있다. 예를 들어 다음과 같은 설정을 한다.
|
||||
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
|
||||
ingress-->|/foo|service1[서비스 service1:4200];
|
||||
ingress-->|/bar|service2[서비스 service2:8080];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service1-->pod1[파드];
|
||||
service1-->pod2[파드];
|
||||
service2-->pod3[파드];
|
||||
service2-->pod4[파드];
|
||||
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 ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
{{< figure src="/ko/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="그림. 인그레스 팬아웃" link="https://mermaid.live/edit#pako:eNqNUk1r2zAY_itCuXRgu7acrak6cupuO23HOAfZkhtRRzaSvA_awgY5lK63wk4J3aDQSw85FOZBf9Hs_IfJtd2k6wa7SC96Pl69D-8RjFLKIIYHkmQT8PrNXiCihDOht0arz7fl4q5a3FZfi9VZMX5mO6BaFL9-FOW30-rsyi6vr8ovp9X1p_Ji_jKUw_L73FSgXBbl5bKazYFjD7k4kEyp0abQAt7OwNn1HA_5juejsWna8mx7eLwdp-mxYvIdj5g3Mj7lz5lRge4J95Hr_qkJiew06KkG4YE7MBoQCJWHzaz1eJc3hrSaLcGD2T2lbWSMs5R6o9X5uZlr_BRCf4FQA_n_hvqbEBMU1JETpfZZDLKEcAFiniS4Rym1lJbpIcO9OI7b2n7PqZ7gfvbBitIklbjnuu7epsfhQLUOPnoRsef_ZWKwRyZRkivNZGu0VuJeGIaPXdDapWn4YATaUK0utq5AVh1sfdxXfn3064-vpc0WNoFsvjbfam-zBIGAFpwyOSWcmj0-CgQAAdQTNmUBxKakLCZ5ogMYiBNDzTNKNHtFuU4lxDFJFLMgyXX69qOIINYyZx1pnxOzKtOWdfIbg1JDXw" >}}
|
||||
|
||||
|
||||
다음과 같은 인그레스가 필요하다.
|
||||
|
||||
|
|
@ -460,25 +428,7 @@ Events:
|
|||
|
||||
이름 기반의 가상 호스트는 동일한 IP 주소에서 여러 호스트 이름으로 HTTP 트래픽을 라우팅하는 것을 지원한다.
|
||||
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client([클라이언트])-. 인그레스-매니지드 <br> 로드 밸런서 .->ingress[인그레스, 178.91.123.132];
|
||||
ingress-->|호스트: foo.bar.com|service1[서비스 service1:80];
|
||||
ingress-->|호스트: bar.foo.com|service2[서비스 service2:80];
|
||||
subgraph 클러스터
|
||||
ingress;
|
||||
service1-->pod1[파드];
|
||||
service1-->pod2[파드];
|
||||
service2-->pod3[파드];
|
||||
service2-->pod4[파드];
|
||||
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 ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
|
||||
class client plain;
|
||||
class cluster cluster;
|
||||
{{</ mermaid >}}
|
||||
{{< figure src="/ko/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="그림. 이름 기반의 가상 호스팅 인그레스" link="https://mermaid.live/edit#pako:eNqNks9r2zAUx_8VoVw2sE1sZ1umjJy6207bMc5BtuTG1JaMJO8HbWGDHErX22DskNANCr3skENhHuwvmpz_YXJsLy7tYBf5oe_3fd7T8zuGEScUIngocL4AL15OQMCiNKFMPZhtP9zo9a9qfVN9Lrfn5fyh7YBqXf7-UeqvZ9X5la2vr_THs-r6vf60ehaKqf62MhHQm1JfbqrlCjj2NGGHgko56ydawH0ydp66juv5jut780nAWp9tT0-2X0pjMhURiDl3QiyciGcnkorXSUTdmSHrn0tjAd0VGg_ndef3Q2pADepBvLsQr4PIImymUb__8ntNWW728J2lrWsK5Zy4s-3FhXn4_K7k3SN5jeT_Wxr1JcrI7p9gKQ9oDPIUJwzESZqiASHEkkrwI4oGcRy3sf0mIWqBRvlbK-IpF2gwHA4nfcbRWLYE33sc0Uf_BTHaLUiUFlJR0YL2mWgQhuFtirenNAX_gkA7VKsbWxd4Vj3Y-thFfn2M6sb3qc2aNgPp3zZttd8JtGBGRYYTYrb8OGAABFAtaEYDiExIaIyLVAUwYKfGWuQEK_qcJIoLiGKcSmpBXCj-6h2LIFKioJ3pIMFmTbLWdfoHV6NUVg" >}}
|
||||
|
||||
|
||||
다음 인그레스는 [호스트 헤더](https://tools.ietf.org/html/rfc7230#section-5.4)에 기반한 요청을
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - thockin
|
||||
## - caseydavenport
|
||||
## - danwinship
|
||||
title: 네트워크 정책
|
||||
content_type: concept
|
||||
weight: 50
|
||||
|
|
@ -54,7 +54,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
|
|||
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는
|
||||
`apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
|
||||
작업에 대한 일반적인 정보는
|
||||
[컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
[컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
|
||||
그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.
|
||||
|
||||
__spec__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
|
||||
|
|
@ -258,7 +258,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을
|
|||
|
||||
## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
|
||||
|
||||
쿠버네티스 {{< skew latestVersion >}}부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다.
|
||||
쿠버네티스 {{< skew currentVersion >}}부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다.
|
||||
|
||||
- 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
|
||||
- TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - maplain
|
||||
title: 서비스 내부 트래픽 정책
|
||||
content_type: concept
|
||||
weight: 45
|
||||
|
|
@ -60,12 +60,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
|
|||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
|
||||
`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다.
|
||||
|
||||
## 제약조건
|
||||
|
||||
* 같은 서비스에서 `externalTrafficPolicy` 가 `Local`로 설정된 경우
|
||||
서비스 내부 트래픽 정책이 사용되지 않는다.
|
||||
클러스터에서 동일하지 않은 다른 서비스에서 이 두 가지 기능은 동시에 사용할 수 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - bprashanth
|
||||
title: 서비스
|
||||
feature:
|
||||
title: 서비스 디스커버리와 로드 밸런싱
|
||||
|
|
@ -122,7 +122,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:11.14.2
|
||||
image: nginx:stable
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: http-web-svc
|
||||
|
|
@ -192,6 +192,7 @@ spec:
|
|||
apiVersion: v1
|
||||
kind: Endpoints
|
||||
metadata:
|
||||
# 여기서의 이름은 서비스의 이름과 일치해야 한다.
|
||||
name: my-service
|
||||
subsets:
|
||||
- addresses:
|
||||
|
|
@ -203,6 +204,10 @@ subsets:
|
|||
엔드포인트 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
서비스를 위한 객체인 [엔드포인트](/ko/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
|
||||
를 만들 때, 새로운 객체의 이름을
|
||||
그것의 서비스 이름과 같게 설정해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
|
||||
링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 _되어서는 안된다_.
|
||||
|
|
@ -394,6 +399,10 @@ iptables 프록시 모드에서 다시 실행된다.
|
|||
최대 세션 고정 시간을 설정할 수도 있다.
|
||||
(기본값은 10800으로, 3시간)
|
||||
|
||||
{{< note >}}
|
||||
윈도우에서, 서비스들의 최대 세션 고정 시간(maximum session sticky time)을 설정하는 것은 지원되지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
## 멀티-포트 서비스
|
||||
|
||||
일부 서비스의 경우, 둘 이상의 포트를 노출해야 한다.
|
||||
|
|
@ -853,6 +862,17 @@ metadata:
|
|||
[...]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="OCI" %}}
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.beta.kubernetes.io/oci-load-balancer-internal: true
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,164 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - aravindhp
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
title: 윈도우에서의 네트워킹
|
||||
content_type: concept
|
||||
weight: 75
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
쿠버네티스는 리눅스 및 윈도우 노드를 지원한다.
|
||||
단일 클러스터 내에 두 종류의 노드를 혼합할 수 있다.
|
||||
이 페이지에서는 윈도우 운영 체제에서의 네트워킹에 대한 개요를 제공한다.
|
||||
|
||||
<!-- body -->
|
||||
## 윈도우에서의 컨테이너 네트워킹 {#networking}
|
||||
|
||||
윈도우 컨테이너에 대한 네트워킹은
|
||||
[CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다.
|
||||
윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다.
|
||||
각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다.
|
||||
호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여
|
||||
컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다.
|
||||
HCS는 컨테이너 관리를 담당하는 반면
|
||||
HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다.
|
||||
|
||||
* 가상 네트워크(vSwitch 생성 포함)
|
||||
* 엔드포인트 / vNIC
|
||||
* 네임스페이스
|
||||
* 정책(패킷 캡슐화, 로드 밸런싱 규칙, ACL, NAT 규칙 등)
|
||||
|
||||
윈도우 HNS(호스트 네트워킹 서비스)와 가상 스위치는
|
||||
네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다.
|
||||
그러나 DNS, 라우트, 메트릭과 같은 많은 구성은
|
||||
리눅스에서와 같이 `/etc/` 내의 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다.
|
||||
컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로
|
||||
호스트에서 컨테이너로 `/etc/resolv.conf`를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다.
|
||||
해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다.
|
||||
따라서 CNI 구현에서는 파일 매핑에 의존하는 대신
|
||||
HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다.
|
||||
|
||||
## 네트워크 모드
|
||||
|
||||
윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다.
|
||||
윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는
|
||||
윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다.
|
||||
윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며,
|
||||
어떠한 경우에 각 CNI를 사용하면 좋은지도 소개한다.
|
||||
|
||||
| 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 |
|
||||
| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
|
||||
| L2bridge | 컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. | MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel 호스트-게이트웨이는 win-bridge를 사용한다. | win-bridge는 L2bridge 네트워크 모드를 사용하고, 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. |
|
||||
| L2Tunnel | 이것은 Azure에서만 사용되는 l2bridge의 특별 케이스다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 전송된다. | MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, [Azure Virtual Network](https://azure.microsoft.com/en-us/services/virtual-network/)에서 제공하는 기능 집합을 활용할 수 있다. 예를 들어, Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. [azure-cni](https://docs.microsoft.com/azure/aks/concepts-network#azure-cni-advanced-networking) 예제를 참고한다. |
|
||||
| Overlay | 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. | 외부 헤더로 캡슐화된다. | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (win-overlay 사용) | win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 Windows Server 2019에서 [KB4489899](https://support.microsoft.com/help/4489899)가 필요하다. |
|
||||
| Transparent ([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) 터널링을 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다. <br/> 패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. <br/> NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. |
|
||||
| NAT (*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. |
|
||||
|
||||
위에서 설명한 대로, [플란넬(Flannel)](https://github.com/coreos/flannel)
|
||||
[CNI 플러그인](https://github.com/flannel-io/cni-plugin)은
|
||||
[VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**베타 지원**, win-overlay에 위임) 및
|
||||
[host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw)(안정적인 지원, win-bridge에 위임)를 통해
|
||||
윈도우에서도 [지원](https://github.com/flannel-io/cni-plugin#windows-support-experimental)한다.
|
||||
|
||||
이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해
|
||||
윈도우의 Flannel 데몬(Flanneld)과 함께 작동할 수 있도록
|
||||
참조 CNI 플러그인(win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다.
|
||||
이 플러그인은 자체 구성 파일 (cni.conf)을 읽고,
|
||||
이를 FlannelD가 생성한 `subnet.env` 파일의 환경 변수와 결합한다.
|
||||
이후 이를 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고,
|
||||
노드-할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인(예: `host-local`)으로 보낸다.
|
||||
|
||||
노드, 파드 및 서비스 오브젝트의 경우,
|
||||
TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.
|
||||
|
||||
* 파드 → 파드(IP)
|
||||
* 파드 → 파드(이름)
|
||||
* 파드 → 서비스(Cluster IP)
|
||||
* 파드 → 서비스(PQDN, 단 "."이 없는 경우에만)
|
||||
* 파드 → 서비스(FQDN)
|
||||
* 파드 → External(IP)
|
||||
* 파드 → External(DNS)
|
||||
* 노드 → 파드
|
||||
* 파드 → 노드
|
||||
|
||||
## IP 주소 관리 (IPAM) {#ipam}
|
||||
|
||||
The following IPAM options are supported on Windows:
|
||||
|
||||
* [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
|
||||
* [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md)(azure-cni 전용)
|
||||
* [Windows Server IPAM](https://docs.microsoft.com/windows-server/networking/technologies/ipam/ipam-top) (IPAM이 설정되지 않은 경우에 대한 폴백(fallback) 옵션)
|
||||
|
||||
## Load balancing and Services
|
||||
|
||||
쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}는
|
||||
논리적 파드 집합 및 네트워크에서 해당 파드로 접근할 수 있는 수단을 정의하는 추상화이다.
|
||||
윈도우 노드가 포함된 클러스터에서, 다음과 같은 종류의 서비스를 사용할 수 있다.
|
||||
|
||||
* `NodePort`
|
||||
* `ClusterIP`
|
||||
* `LoadBalancer`
|
||||
* `ExternalName`
|
||||
|
||||
윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 차이점을 갖는다.
|
||||
[윈도우 컨테이너 네트워킹에 대한 마이크로소프트 문서](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)에서
|
||||
상세 사항과 배경 지식을 제공한다.
|
||||
|
||||
윈도우에서는 다음 설정을 사용하여
|
||||
서비스 및 로드 밸런싱 동작을 구성할 수 있다.
|
||||
|
||||
{{< table caption="윈도우 서비스 구성" >}}
|
||||
| 기능 | 설명 | 지원하는 최소 윈도우 OS 빌드 | 활성화하는 방법 |
|
||||
| ------- | ----------- | -------------------------- | ------------- |
|
||||
| 세션 어피니티 | 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 한다. | Windows Server 2022 | `service.spec.sessionAffinity`를 "ClientIP"로 설정 |
|
||||
| 서버 직접 반환 (DSR, Direct Server Return) | IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 설정된 상태로 도착한다. | Windows Server 2019 | kube-proxy에 `--feature-gates="WinDSR=true" --enable-dsr=true` 플래그를 설정한다. |
|
||||
| 목적지 보존(Preserve-Destination) | 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 목적지 서비스의 가상 IP를 보존한다. 또한 노드-노드 전달을 비활성화한다. | Windows Server, version 1903 | 서비스 어노테이션에 `"preserve-destination": "true"`를 설정하고 kube-proxy에 DSR을 활성화한다. |
|
||||
| IPv4/IPv6 이중 스택 네트워킹 | 클러스터 내/외부에 네이티브 IPv4-to-IPv4 통신 및 IPv6-to-IPv6 통신 활성화 | Windows Server 2019 | [IPv4/IPv6 이중 스택](#ipv4ipv6-dual-stack)을 참고한다. |
|
||||
| 클라이언트 IP 보존 | 인그레스 트래픽의 소스 IP가 유지되도록 한다. 또한 노드-노드 전달을 비활성화한다. | Windows Server 2019 | Set `service.spec.externalTrafficPolicy`를 "Local"로 설정하고 kube-proxy에 DSR을 활성화한다. |
|
||||
{{< /table >}}
|
||||
|
||||
{{< warning >}}
|
||||
목적지 노드가 Windows Server 2022를 실행 중인 경우, 오버레이 네트워킹에서 NodePort 서비스에 문제가 있음이 알려져 있다.
|
||||
이 이슈를 완전히 피하려면, 서비스에 `externalTrafficPolicy: Local`를 설정한다.
|
||||
|
||||
KB5005619 또는 그 이상이 설치된 Windows Server 2022의 경우, l2bridge 네트워크에서 파드 간 연결성에 문제가 있음이 알려져 있다.
|
||||
이 이슈를 우회하고 파드 간 연결성을 복구하기 위해, kube-proxy의 WinDSR 기능을 비활성화할 수 있다.
|
||||
|
||||
이 이슈들을 해결하기 위해서는 운영 체제를 패치해야 한다.
|
||||
이와 관련해서는 https://github.com/microsoft/Windows-Containers/issues/204 를 참고한다.
|
||||
{{< /warning >}}
|
||||
|
||||
## 제한
|
||||
|
||||
다음 네트워킹 기능은 윈도우 노드에서 지원되지 _않는다_.
|
||||
|
||||
* 호스트 네트워킹 모드
|
||||
* 노드 자체에서 로컬 NodePort로의 접근(다른 노드 또는 외부 클라이언트에서는 가능)
|
||||
* 단일 서비스에 대해 64개를 초과하는 백엔드 파드 (또는 고유한 목적지 주소)
|
||||
* 오버레이 네트워크에 연결된 윈도우 파드 간의 IPv6 통신
|
||||
* non-DSR 모드에서의 로컬 트래픽 정책(Local Traffic Policy)
|
||||
* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신.
|
||||
특히, 윈도우 데이터 플레인([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은
|
||||
ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다.
|
||||
* 동일한 네트워크 내의 목적지로 전달되는 ICMP 패킷(예: ping을 통한 파드 간 통신)은
|
||||
예상대로 제한 없이 작동한다.
|
||||
* TCP/UDP 패킷은 예상대로 제한 없이 작동한다.
|
||||
* 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은
|
||||
치환될 수 없으므로 소스로 다시 라우팅되지 않는다.
|
||||
* TCP/UDP 패킷은 여전히 치환될 수 있기 때문에 `ping <destination>`을
|
||||
`curl <destination>`으로 대체하여 외부와의 연결을 디버깅할 수 있다.
|
||||
|
||||
다른 제한도 존재한다.
|
||||
|
||||
* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는
|
||||
현재 `CHECK` 구현 누락으로 인해
|
||||
[CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0을 구현하지 않는다.
|
||||
* Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다.
|
||||
* 노드-파드 연결은 Flannel v0.12.0(또는 그 이상) 상의 로컬 파드에서만 가능하다.
|
||||
* Flannel은 VNI 4096 및 UDP 4789 포트만 사용하도록 제한된다.
|
||||
이 파라미터에 대한 더 자세한 사항은
|
||||
공식 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 백엔드 문서를 참조한다.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - jsafrane
|
||||
## - saad-ali
|
||||
## - msau42
|
||||
## - xing-yang
|
||||
## - pohly
|
||||
title: 임시 볼륨
|
||||
content_type: concept
|
||||
weight: 30
|
||||
|
|
@ -207,7 +207,7 @@ spec:
|
|||
즉각적인 바인딩을 사용하는 경우,
|
||||
스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다.
|
||||
|
||||
[리소스 소유권](/ko/docs/concepts/architecture/garbage-collection/#owners-dependents) 관점에서,
|
||||
[리소스 소유권](/docs/concepts/workloads/controllers/garbage-collection/#owners-dependents) 관점에서,
|
||||
일반 임시 스토리지를 갖는 파드는
|
||||
해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다.
|
||||
파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데,
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - jsafrane
|
||||
## - saad-ali
|
||||
## - thockin
|
||||
## - msau42
|
||||
## - xing-yang
|
||||
title: 퍼시스턴트 볼륨
|
||||
feature:
|
||||
title: 스토리지 오케스트레이션
|
||||
|
|
@ -540,6 +540,15 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
|
|||
* RWX - ReadWriteMany
|
||||
* RWOP - ReadWriteOncePod
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스는 볼륨 접근 모드를 이용해 퍼시스턴트볼륨클레임과 퍼시스턴트볼륨을 연결한다.
|
||||
경우에 따라 볼륨 접근 모드는 퍼시스턴트볼륨을 탑재할 수 있는 위치도 제한한다.
|
||||
볼륨 접근 모드는 스토리지를 마운트 한 후에는 쓰기 보호를 적용하지 않는다.
|
||||
접근 모드가 ReadWriteOnce, ReadOnlyMany 혹은 ReadWriteMany로 지정된 경우에도 접근 모드는 볼륨에 제약 조건을 설정하지 않는다.
|
||||
예를 들어 퍼시스턴트볼륨이 ReadOnlyMany로 생성되었다 하더라도, 해당 퍼시스턴트 볼륨이 읽기 전용이라는 것을 보장하지 않는다.
|
||||
만약 접근 모드가 ReadWriteOncePod로 지정된 경우, 볼륨에 제한이 설정되어 단일 파드에만 마운트 할 수 있게 된다.
|
||||
{{< /note >}}
|
||||
|
||||
> __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
|
||||
|
||||
|
||||
|
|
@ -673,7 +682,7 @@ spec:
|
|||
|
||||
### 리소스
|
||||
|
||||
파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)이 볼륨과 클레임 모두에 적용된다.
|
||||
파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 [리소스 모델](https://git.k8s.io/design-proposals-archive/scheduling/resources.md)이 볼륨과 클레임 모두에 적용된다.
|
||||
|
||||
### 셀렉터
|
||||
|
||||
|
|
@ -1012,7 +1021,7 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
|
|||
|
||||
* [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기
|
||||
* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기
|
||||
* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md) 읽어보기
|
||||
|
||||
### API 레퍼런스 {#reference}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - jsafrane
|
||||
## - saad-ali
|
||||
## - thockin
|
||||
## - msau42
|
||||
title: 스토리지 클래스
|
||||
content_type: concept
|
||||
weight: 30
|
||||
|
|
@ -87,7 +87,7 @@ volumeBindingMode: Immediate
|
|||
여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이
|
||||
이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와
|
||||
함께 제공된다). 또한, 쿠버네티스에서 정의한
|
||||
[사양](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)을
|
||||
[사양](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)을
|
||||
따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다.
|
||||
외부 프로비저너의 작성자는 코드의 수명, 프로비저너의
|
||||
배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인
|
||||
|
|
@ -534,7 +534,7 @@ vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티
|
|||
|
||||
* 쿠버네티스 내부의 가상 SAN 정책 지원
|
||||
|
||||
Vsphere 인프라스트럭쳐(Vsphere Infrastructure (VI)) 관리자는
|
||||
Vsphere 인프라스트럭처(Vsphere Infrastructure (VI)) 관리자는
|
||||
동적 볼륨 프로비저닝 중에 사용자 정의 가상 SAN 스토리지
|
||||
기능을 지정할 수 있다. 이제 동적 볼륨 프로비저닝 중에 스토리지
|
||||
기능의 형태로 성능 및 가용성과 같은 스토리지 요구 사항을 정의할
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## reviewers:
|
||||
## - jsafrane
|
||||
## - saad-ali
|
||||
## - thockin
|
||||
## - msau42
|
||||
title: 볼륨
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
|
@ -64,7 +64,9 @@ weight: 10
|
|||
|
||||
쿠버네티스는 여러 유형의 볼륨을 지원한다.
|
||||
|
||||
### awsElasticBlockStore {#awselasticblockstore}
|
||||
### awsElasticBlockStore (사용 중단됨) {#awselasticblockstore}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="deprecated" >}}
|
||||
|
||||
`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS)
|
||||
[EBS 볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를
|
||||
|
|
@ -135,7 +137,9 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
|
|||
컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
|
||||
플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다.
|
||||
|
||||
### azureDisk {#azuredisk}
|
||||
### azureDisk (사용 중단됨) {#azuredisk}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="deprecated" >}}
|
||||
|
||||
`azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다.
|
||||
|
||||
|
|
@ -158,7 +162,9 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
|
|||
컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면,
|
||||
`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다.
|
||||
|
||||
### azureFile {#azurefile}
|
||||
### azureFile (사용 중단됨) {#azurefile}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
|
||||
|
||||
`azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에
|
||||
마운트한다.
|
||||
|
|
@ -201,7 +207,9 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를
|
|||
|
||||
더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다.
|
||||
|
||||
### cinder
|
||||
### cinder (사용 중단됨)
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="deprecated" >}}
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스는 오픈스택 클라우드 공급자로 구성되어야 한다.
|
||||
|
|
@ -295,15 +303,17 @@ spec:
|
|||
|
||||
### downwardAPI {#downwardapi}
|
||||
|
||||
`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 한다.
|
||||
이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다.
|
||||
`downwardAPI` 볼륨은 애플리케이션에서 {{< glossary_tooltip term_id="downward-api" text="다운워드(downward) API" >}}
|
||||
데이터를 사용할 수 있도록 한다. 볼륨 내에서 노출된 데이터를
|
||||
일반 텍스트 형식의 읽기 전용 파일로 찾을 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
다운워드 API를 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API
|
||||
업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
|
||||
더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
|
||||
를 참고한다.
|
||||
|
||||
### emptyDir {#emptydir}
|
||||
|
||||
|
|
@ -390,7 +400,9 @@ Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이
|
|||
|
||||
더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다.
|
||||
|
||||
### gcePersistentDisk
|
||||
### gcePersistentDisk (사용 중단됨) {#gcepersistentdisk}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="deprecated" >}}
|
||||
|
||||
`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진(GCE)
|
||||
[영구 디스크](https://cloud.google.com/compute/docs/disks)(PD)를 파드에 마운트한다.
|
||||
|
|
@ -1146,7 +1158,7 @@ CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는
|
|||
컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를
|
||||
정의하여 임의의 스토리지 시스템을 컨테이너 워크로드에 노출시킨다.
|
||||
|
||||
더 자세한 정보는 [CSI 디자인 제안](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)을 읽어본다.
|
||||
더 자세한 정보는 [CSI 디자인 제안](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md)을 읽어본다.
|
||||
|
||||
{{< note >}}
|
||||
CSI 규격 버전 0.2와 0.3에 대한 지원은 쿠버네티스 v1.13에서 사용중단(deprecated)
|
||||
|
|
@ -1240,6 +1252,20 @@ CSI 설정 변경 없이 평소와 같이
|
|||
CSI 드라이버의 개발 방법에 대한 더 자세한 정보는
|
||||
[쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
|
||||
|
||||
#### 윈도우 CSI 프록시
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
|
||||
|
||||
CSI 노드 플러그인은 디스크 장치 검색 및 파일 시스템 마운트 같은
|
||||
다양한 권한이 부여된 작업을 수행해야 한다. 이러한 작업은
|
||||
호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우, 일반적으로 컨테이너형
|
||||
CSI 노드 플러그인은 권한 있는 컨테이너로 배포된다. 윈도우 워커 노드의 경우,
|
||||
각 윈도우 노드에 미리 설치해야 하는 커뮤니티판 스탠드얼론(stand-alone) 바이너리인
|
||||
[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 이용하여
|
||||
컨테이너형 CSI 노드 플러그인에 대한 권한 있는 작업을 지원한다.
|
||||
|
||||
자세한 내용은 배포할 CSI 플러그인의 배포 가이드를 참고한다.
|
||||
|
||||
#### 인-트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
|
@ -1256,6 +1282,14 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트
|
|||
`CSIMigration` 을 지원하고 해당 CSI 드라이버가 구현된 인-트리 플러그인은
|
||||
[볼륨 유형들](#volume-types)에 나열되어 있다.
|
||||
|
||||
다음 인-트리 플러그인은 윈도우 노드에서 퍼시스턴트볼륨을 지원한다.
|
||||
|
||||
* [`awsElasticBlockStore`](#awselasticblockstore)
|
||||
* [`azureDisk`](#azuredisk)
|
||||
* [`azureFile`](#azurefile)
|
||||
* [`gcePersistentDisk`](#gcepersistentdisk)
|
||||
* [`vsphereVolume`](#vspherevolume)
|
||||
|
||||
### flexVolume
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="deprecated" >}}
|
||||
|
|
@ -1267,6 +1301,12 @@ FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된
|
|||
파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다.
|
||||
더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다.
|
||||
|
||||
호스트에 PowerShell 스크립트로 배포된 다음과 같은
|
||||
FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다.
|
||||
|
||||
* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
|
||||
* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
|
||||
|
||||
{{< note >}}
|
||||
FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,71 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jingxu97
|
||||
# - mauriciopoppe
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
# - aravindhp
|
||||
title: 윈도우 스토리지
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 윈도우 운영 체제에서의 스토리지 개요를 제공한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 퍼시스턴트 스토리지 {#storage}
|
||||
|
||||
윈도우는 계층 구조의 파일시스템 드라이버를 사용하여
|
||||
컨테이너 레이어를 마운트하고 NTFS 기반 파일시스템의 복제본을 생성한다.
|
||||
컨테이너 내의 모든 파일 경로는 해당 컨테이너 컨텍스트 내에서만 인식 가능하다.
|
||||
|
||||
* 도커를 사용할 때, 볼륨 마운트는 컨테이너 내의 디렉토리로만 지정할 수 있으며, 개별 파일로는 지정할 수 없다.
|
||||
이 제약 사항은 containerd에는 적용되지 않는다.
|
||||
* 볼륨 마운트는 파일 또는 디렉토리를 호스트 파일시스템으로 투영(project)할 수 없다.
|
||||
* 윈도우 레지스트리와 SAM 데이터케이스에 쓰기 권한이 항상 필요하기 때문에,
|
||||
읽기 전용 파일시스템은 지원되지 않는다. 다만, 읽기 전용 볼륨은 지원된다.
|
||||
* 볼륨 사용자-마스크 및 퍼미션은 사용할 수 있다.
|
||||
호스트와 컨테이너 간에 SAM이 공유되지 않기 때문에, 둘 간의 매핑이 존재하지 않는다.
|
||||
모든 퍼미션은 해당 컨테이너 컨텍스트 내에서만 처리된다.
|
||||
|
||||
결과적으로, 윈도우 노드에서는 다음 스토리지 기능이 지원되지 않는다.
|
||||
|
||||
* 볼륨 서브패스(subpath) 마운트: 윈도우 컨테이너에는 전체 볼륨만 마운트할 수 있다.
|
||||
* 시크릿을 위한 서브패스 볼륨 마운팅
|
||||
* 호스트 마운트 투영(projection)
|
||||
* 읽기 전용 루트 파일시스템 (매핑된 볼륨은 여전히 `readOnly`를 지원한다)
|
||||
* 블록 디바이스 매핑
|
||||
* 메모리를 스토리지 미디어로 사용하기 (예를 들어, `emptyDir.medium`를 `Memory`로 설정하는 경우)
|
||||
* uid/gid, 사용자 별 리눅스 파일시스템 권한과 같은 파일시스템 기능
|
||||
* [DefaultMode을 이용하여 시크릿 퍼미션](/ko/docs/concepts/configuration/secret/#시크릿-파일-퍼미션) 설정하기 (UID/GID 의존성 때문에)
|
||||
* NFS 기반 스토리지/볼륨 지원
|
||||
* 마운트된 볼륨 확장하기 (resizefs)
|
||||
|
||||
쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 사용하여
|
||||
데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는
|
||||
복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다.
|
||||
특정 스토리지 백엔드 또는 프로토콜과 연관된 퍼시스턴트 볼륨의 관리는
|
||||
볼륨 프로비저닝/디프로비저닝/리사이징,
|
||||
쿠버네티스 노드로의 볼륨 연결(attaching) 및 해제(detaching),
|
||||
데이터를 보존해야 하는 파드 내 개별 컨테이너로의 볼륨 마운트 및 해제 같은 동작을 포함한다.
|
||||
|
||||
볼륨 관리 구성 요소는 쿠버네티스 볼륨
|
||||
[플러그인](/ko/docs/concepts/storage/volumes/#volume-types) 형태로 제공된다.
|
||||
윈도우는 다음의 광역 쿠버네티스 볼륨 플러그인 클래스를 지원한다.
|
||||
|
||||
* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexVolume)
|
||||
* FlexVolumes은 1.23부터 사용 중단되었음에 유의한다.
|
||||
* [`CSI 플러그인`](/ko/docs/concepts/storage/volumes/#csi)
|
||||
|
||||
##### 인-트리(In-tree) 볼륨 플러그인
|
||||
|
||||
다음의 인-트리 플러그인은 윈도우 노드에서의 퍼시스턴트 스토리지를 지원한다.
|
||||
|
||||
* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore)
|
||||
* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk)
|
||||
* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile)
|
||||
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk)
|
||||
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume)
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "쿠버네티스에서의 윈도우"
|
||||
weight: 50
|
||||
---
|
||||
|
|
@ -0,0 +1,387 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
# - perithompson
|
||||
title: 쿠버네티스에서의 윈도우 컨테이너
|
||||
content_type: concept
|
||||
weight: 65
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다.
|
||||
[윈도우 컨테이너](https://aka.ms/windowscontainers)는
|
||||
프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여,
|
||||
데브옵스(DevOps) 사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다.
|
||||
|
||||
윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은
|
||||
워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로,
|
||||
운영 체제와 관계없이
|
||||
배포 전반에 걸쳐 운영 효율성이 향상된다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 쿠버네티스에서의 윈도우 노드
|
||||
|
||||
쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면,
|
||||
기존 리눅스 클러스터에 윈도우 노드를 추가한다.
|
||||
쿠버네티스에서 {{< glossary_tooltip text="파드" term_id="pod" >}} 내의 윈도우 컨테이너를 스케줄링하는 것은
|
||||
리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다.
|
||||
|
||||
윈도우 컨테이너를 실행하려면,
|
||||
쿠버네티스 클러스터가 여러 운영 체제를 포함하고 있어야 한다.
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 리눅스에서만 실행할 수 있는 반면,
|
||||
워커 노드는 윈도우 또는 리눅스를 실행할 수 있다.
|
||||
|
||||
{{< glossary_tooltip text="노드" term_id="node" >}}의 운영 체제가
|
||||
Windows Server 2019인 경우에만
|
||||
윈도우 노드로써 [사용할 수 있다](#windows-os-version-support).
|
||||
|
||||
이 문서에서 *윈도우 컨테이너*라는 용어는 프로세스 격리 기반의 윈도우 컨테이너를 의미한다.
|
||||
쿠버네티스는 [Hyper-V 격리](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) 기반의
|
||||
윈도우 컨테이너를 지원하지 않는다.
|
||||
|
||||
## 호환성 및 제한 {#limitations}
|
||||
|
||||
일부 노드 기능은 특정 [컨테이너 런타임](#container-runtime)을 사용할 때에만 이용 가능하며,
|
||||
윈도우 노드에서 사용할 수 없는 기능도 있다.
|
||||
예시는 다음과 같다.
|
||||
|
||||
* HugePages: 윈도우 컨테이너에서 지원되지 않음
|
||||
* 특권을 가진(Privileged) 컨테이너: 윈도우 컨테이너에서 지원되지 않음.
|
||||
[HostProcess 컨테이너](/docs/tasks/configure-pod-container/create-hostprocess-pod/)가 비슷한 기능을 제공한다.
|
||||
* TerminationGracePeriod: containerD를 필요로 한다.
|
||||
|
||||
공유 네임스페이스(shared namespaces)의 모든 기능이 지원되는 것은 아니다.
|
||||
자세한 내용은 [API 호환성](#api)을 참조한다.
|
||||
|
||||
[윈도우 OS 버전 호환성](#windows-os-version-support)에서
|
||||
쿠버네티스와의 동작이 테스트된 윈도우 버전 상세사항을 확인한다.
|
||||
|
||||
API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다.
|
||||
그러나, 주요 기능에서 몇 가지 주목할 만한 차이점이 있으며,
|
||||
이 섹션에서 소개된다.
|
||||
|
||||
### 리눅스와의 비교 {#compatibility-linux-similarities}
|
||||
|
||||
윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다.
|
||||
이 섹션에서는 몇 가지 주요 워크로드 추상화 및 이들이 윈도우에서 어떻게 매핑되는지를 다룬다.
|
||||
|
||||
* [파드](/ko/docs/concepts/workloads/pods/)
|
||||
|
||||
파드는 쿠버네티스의 기본 빌딩 블록이며,
|
||||
이는 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위임을 의미한다.
|
||||
동일한 파드에 윈도우 컨테이너와 리눅스 컨테이너를 배포할 수 없다.
|
||||
파드의 모든 컨테이너는 단일 노드로 스케줄되며 이 때 각 노드는 특정 플랫폼 및 아키텍처를 갖는다.
|
||||
다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.
|
||||
|
||||
* 프로세스 격리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너
|
||||
* 파드의 `status` 필드
|
||||
* 준비성 프로브(readinessprobe), 활성 프로브(liveness probe) 및 시작 프로브(startup probe)
|
||||
* postStart 및 preStop 컨테이너 라이프사이클 훅
|
||||
* 컨피그맵(ConfigMap), 시크릿(Secrets): 환경 변수 또는 볼륨 형태로
|
||||
* `emptyDir` 볼륨
|
||||
* 명명된 파이프 호스트 마운트
|
||||
* 리소스 제한
|
||||
* OS 필드:
|
||||
|
||||
특정 파드가 윈도우 컨테이너를 사용하고 있다는 것을 나타내려면 `.spec.os.name` 필드를 `windows`로 설정해야 한다.
|
||||
이 필드가 인식되도록 하기 위해서는 `IdentifyPodOS` 기능 게이트가 활성화되어야 한다.
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스 1.24부터, `IdentifyPodOS` 기능 게이트는 베타 단계이며 기본적으로 활성화되어 있다.
|
||||
{{< /note >}}
|
||||
|
||||
`IdentifyPodOS` 기능 게이트가 활성화되어 있고 `.spec.os.name` 필드를 `windows`로 설정했다면,
|
||||
해당 파드의 `.spec` 내의 다음 필드는 설정하지 않아야 한다.
|
||||
|
||||
* `spec.hostPID`
|
||||
* `spec.hostIPC`
|
||||
* `spec.securityContext.seLinuxOptions`
|
||||
* `spec.securityContext.seccompProfile`
|
||||
* `spec.securityContext.fsGroup`
|
||||
* `spec.securityContext.fsGroupChangePolicy`
|
||||
* `spec.securityContext.sysctls`
|
||||
* `spec.shareProcessNamespace`
|
||||
* `spec.securityContext.runAsUser`
|
||||
* `spec.securityContext.runAsGroup`
|
||||
* `spec.securityContext.supplementalGroups`
|
||||
* `spec.containers[*].securityContext.seLinuxOptions`
|
||||
* `spec.containers[*].securityContext.seccompProfile`
|
||||
* `spec.containers[*].securityContext.capabilities`
|
||||
* `spec.containers[*].securityContext.readOnlyRootFilesystem`
|
||||
* `spec.containers[*].securityContext.privileged`
|
||||
* `spec.containers[*].securityContext.allowPrivilegeEscalation`
|
||||
* `spec.containers[*].securityContext.procMount`
|
||||
* `spec.containers[*].securityContext.runAsUser`
|
||||
* `spec.containers[*].securityContext.runAsGroup`
|
||||
|
||||
위의 리스트에서 와일드카드(`*`)는 목록의 모든 요소를 가리킨다.
|
||||
예를 들어, `spec.containers[*].securityContext`는
|
||||
모든 컨테이너의 시큐리티컨텍스트(SecurityContext) 오브젝트를 나타낸다.
|
||||
위의 필드 중 하나라도 설정되어 있으면, API 서버는 해당 파드는 수용하지 않을 것이다.
|
||||
|
||||
* 다음과 같은 [워크로드 리소스](/ko/docs/concepts/workloads/controllers/):
|
||||
* 레플리카셋(ReplicaSet)
|
||||
* 디플로이먼트(Deployment)
|
||||
* 스테이트풀셋(StatefulSet)
|
||||
* 데몬셋(DaemonSet)
|
||||
* 잡(Job)
|
||||
* 크론잡(CronJob)
|
||||
* 레플리케이션컨트롤러(ReplicationController)
|
||||
* {{< glossary_tooltip text="서비스" term_id="service" >}}
|
||||
[로드 밸런싱과 서비스](#load-balancing-and-services)에서 상세 사항을 확인한다.
|
||||
|
||||
파드, 워크로드 리소스 및 서비스는
|
||||
쿠버네티스에서 윈도우 워크로드를 관리하는 데 중요한 요소이다.
|
||||
그러나 그 자체만으로는 동적인 클라우드 네이티브 환경에서
|
||||
윈도우 워크로드의 적절한 라이프사이클 관리를 수행하기에 충분하지 않다.
|
||||
|
||||
* `kubectl exec`
|
||||
* 파드 및 컨테이너 메트릭
|
||||
* {{< glossary_tooltip text="Horizontal pod autoscaling" term_id="horizontal-pod-autoscaler" >}}
|
||||
* {{< glossary_tooltip text="리소스 쿼터(Resource quota)" term_id="resource-quota" >}}
|
||||
* 스케쥴러 선점(preemption)
|
||||
|
||||
### kubelet을 위한 명령줄 옵션 {#kubelet-compatibility}
|
||||
|
||||
윈도우에서는 일부 kubelet 명령줄 옵션이 다르게 동작하며, 아래에 설명되어 있다.
|
||||
|
||||
* `--windows-priorityclass`를 사용하여 kubelet 프로세스의 스케줄링 우선 순위를 설정할 수 있다.
|
||||
([CPU 리소스 관리](/ko/docs/concepts/configuration/windows-resource-management/#resource-management-cpu) 참고)
|
||||
* `--kube-reserved`, `--system-reserved` 및 `--eviction-hard` 플래그는
|
||||
[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 업데이트한다.
|
||||
* `--enforce-node-allocable`을 이용한 축출은 구현되어 있지 않다.
|
||||
* `--eviction-hard` 및 `--eviction-soft`를 이용한 축출은 구현되어 있지 않다.
|
||||
* 윈도우 노드에서 실행되는 kubelet은 메모리 및 CPU 제한을 받지 않는다.
|
||||
`NodeAllocatable`에서 `--kube-reserved`와 `--system-reserved`가 차감될 뿐이며
|
||||
워크로드에 제공될 리소스는 보장되지 않는다.
|
||||
추가 정보는 [윈도우 노드의 리소스 관리](/ko/docs/concepts/configuration/windows-resource-management/#resource-reservation)를
|
||||
참고한다.
|
||||
* `MemoryPressure` 컨디션은 구현되어 있지 않다.
|
||||
* kubelet은 메모리 부족(OOM, Out-of-Memory) 축출 동작을 수행하지 않는다.
|
||||
|
||||
### API 호환성 {#api}
|
||||
|
||||
운영 체제와 컨테이너 런타임의 차이로 인해, 윈도우에 대해 쿠버네티스 API가 동작하는 방식에 미묘한 차이가 있다.
|
||||
일부 워크로드 속성은 리눅스에 맞게 설계되었으며, 이로 인해 윈도우에서 실행되지 않는다.
|
||||
|
||||
높은 수준에서, OS 개념에 대해 다음과 같은 차이점이 존재한다.
|
||||
|
||||
* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다.
|
||||
사용자와 그룹 이름은 정식 이름이 아니다.
|
||||
UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다.
|
||||
윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된
|
||||
더 큰 이진 [보안 식별자](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers)(SID)를 사용한다.
|
||||
이 데이터베이스는 호스트와 컨테이너 간에 또는
|
||||
컨테이너들 간에 공유되지 않는다.
|
||||
* 파일 퍼미션 - 윈도우는 SID 기반 접근 제어 목록을 사용하는 반면,
|
||||
리눅스와 같은 POSIX 시스템은 오브젝트 권한 및 UID+GID 기반의 비트마스크(bitmask)를 사용하며,
|
||||
접근 제어 목록도 선택적으로 사용한다.
|
||||
* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다.
|
||||
Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다.
|
||||
하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다.
|
||||
* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며,
|
||||
다음 중 하나 이상을 구현할 수 있다.
|
||||
* UI 스레드는 `WM_CLOSE` 등의 잘 정의된(well-defined) 메시지를 처리한다.
|
||||
* 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 Ctrl-c 또는 Ctrl-break를 처리한다.
|
||||
* 서비스는 `SERVICE_CONTROL_STOP` 제어 코드를 수용할 수 있는
|
||||
Service Control Handler 함수를 등록한다.
|
||||
|
||||
컨테이너 종료 코드는 리눅스와 동일하게 성공이면 0, 실패이면 0이 아닌 디른 수이다.
|
||||
상세 오류 코드는 윈도우와 리눅스 간에 다를 수 있다.
|
||||
그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다.
|
||||
|
||||
#### 컨테이너 명세의 필드 호환성 {#compatibility-v1-pod-spec-containers}
|
||||
|
||||
다음 목록은 윈도우와 리눅스에서
|
||||
파드 컨테이너 명세가 어떻게 다르게 동작하는지 기술한다.
|
||||
|
||||
* Huge page는 윈도우 컨테이너 런타임에서 구현되지 않았으며,
|
||||
따라서 사용할 수 없다. 컨테이너에 대해 구성할 수 없는(not configurable)
|
||||
[사용자 권한(user privilege) 어설트(assert)](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가
|
||||
필요하다.
|
||||
* `requests.cpu` 및 `requests.memory` - 요청(requests)이 노드의 사용 가능한 리소스에서 차감되며,
|
||||
이는 노드 오버프로비저닝을 방지하기 위해 사용될 수 있다.
|
||||
그러나, 오버프로비저닝된 노드 내에서 리소스를 보장하기 위해서는 사용될 수 없다.
|
||||
운영자가 오버 프로비저닝을 완전히 피하려는 경우
|
||||
모범 사례로 모든 컨테이너에 적용해야 한다.
|
||||
* `securityContext.allowPrivilegeEscalation` -
|
||||
어떠한 기능도 연결되지 않아서, 윈도우에서는 사용할 수 없다.
|
||||
* `securityContext.capabilities` -
|
||||
POSIX 기능은 윈도우에서 구현되지 않았다.
|
||||
* `securityContext.privileged` -
|
||||
윈도우는 특권을 가진(privileged) 컨테이너를 지원하지 않는다.
|
||||
* `securityContext.procMount` -
|
||||
윈도우에는 `/proc` 파일시스템이 없다.
|
||||
* `securityContext.readOnlyRootFilesystem` -
|
||||
윈도우에서는 사용할 수 없으며,
|
||||
이는 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행될 때 쓰기 권한이 필요하기 때문이다.
|
||||
* `securityContext.runAsGroup` -
|
||||
윈도우에서는 GID가 지원되지 않으므로 사용할 수 없다.
|
||||
* `securityContext.runAsNonRoot` -
|
||||
이 설정은 컨테이너가 `ContainerAdministrator` 사용자로 실행되는 것을 방지하는데,
|
||||
이는 리눅스의 root 사용자와 가장 가까운 윈도우 역할이다.
|
||||
* `securityContext.runAsUser` -
|
||||
대신 [`runAsUserName`](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
|
||||
사용한다.
|
||||
* `securityContext.seLinuxOptions` -
|
||||
SELinux는 리눅스 전용이므로 윈도우에서는 사용할 수 없다.
|
||||
* `terminationMessagePath` -
|
||||
윈도우가 단일 파일 매핑을 지원하지 않음으로 인하여 몇 가지 제한이 있다.
|
||||
기본값은 `/dev/termination-log`이며,
|
||||
이 경로가 기본적으로 윈도우에 존재하지 않기 때문에 정상적으로 작동한다.
|
||||
|
||||
#### 파드 명세의 필드 호환성 {#compatibility-v1-pod}
|
||||
|
||||
다음 목록은 윈도우와 리눅스에서 파드 명세가 어떻게 다르게 동작하는지 기술한다.
|
||||
|
||||
* `hostIPC` 및 `hostpid` - 호스트 네임스페이스 공유 기능은 윈도우에서 사용할 수 없다.
|
||||
* `hostNetwork` - 윈도우 운영 체제에서 호스트 네트워크 공유 기능을 지원하지 않는다.
|
||||
* `dnsPolicy` - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에
|
||||
`dnsPolicy`를 `ClusterFirstWithHostNet`로 설정할 수 없다.
|
||||
파드는 항상 컨테이너 네트워크와 함께 동작한다.
|
||||
* `podSecurityContext` (하단 참조)
|
||||
* `shareProcessNamespace` - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 의존한다.
|
||||
윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다.
|
||||
네트워크만 공유할 수 있다.
|
||||
* `terminationGracePeriodSeconds` - 이것은 윈도우용 도커에서 완전히 구현되지 않았다.
|
||||
[GitHub 이슈](https://github.com/moby/moby/issues/25982)를 참고한다.
|
||||
현재 동작은 `ENTRYPOINT` 프로세스가 `CTRL_SHUTDOWN_EVENT`로 전송된 다음,
|
||||
윈도우가 기본적으로 5초를 기다린 후,
|
||||
마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다.
|
||||
5초 기본값은 실제로는
|
||||
[컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) 윈도우 레지스트리에 있으므로
|
||||
컨테이너를 빌드할 때 재정의할 수 있다.
|
||||
* `volumeDevices` - 이것은 베타 기능이며, 윈도우에서 구현되지 않았다.
|
||||
윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다.
|
||||
* `volumes`
|
||||
* `emptyDir` 볼륨을 정의한 경우, 이 볼륨의 소스(source)를 `memory`로 설정할 수는 없다.
|
||||
* `mountPropagation` - 마운트 전파(propagation)는 윈도우에서 지원되지 않으므로
|
||||
이 필드는 활성화할 수 없다.
|
||||
|
||||
#### 파드 시큐리티 컨텍스트의 필드 호환성 {#compatibility-v1-pod-spec-containers-securitycontext}
|
||||
|
||||
파드 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)의 모든 필드는 윈도우에서 작동하지 않는다.
|
||||
|
||||
## 노드 문제 감지기
|
||||
|
||||
노드 문제 감지기([노드 헬스 모니터링하기](/ko/docs/tasks/debug/debug-cluster/monitor-node-health/) 참조)는
|
||||
기초적인 윈도우 지원을 포함한다.
|
||||
더 자세한 정보는 프로젝트의
|
||||
[GitHub 페이지](https://github.com/kubernetes/node-problem-detector#windows)를 참고한다.
|
||||
|
||||
## 퍼즈(pause) 컨테이너
|
||||
|
||||
쿠버네티스 파드에서, 컨테이너를 호스팅하기 위해 먼저 "퍼즈" 컨테이너라는 인프라 컨테이너가 생성된다.
|
||||
리눅스에서, 파드를 구성하는 cgroup과 네임스페이스가 계속 유지되기 위해서는 프로세스가 필요하며,
|
||||
퍼즈 프로세스가 이를 담당한다.
|
||||
동일한 파드에 속한 (인프라 및 워커) 컨테이너는
|
||||
공통의 네트워크 엔드포인트(공통 IPv4/IPv6 주소, 공통 네트워크 포트 공간)를 공유한다.
|
||||
쿠버네티스는 퍼즈 컨테이너를 사용하여
|
||||
워커 컨테이너가 충돌하거나 재시작하여도 네트워킹 구성을 잃지 않도록 한다.
|
||||
|
||||
쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다.
|
||||
쿠버네티스 v{{< skew currentVersion >}}의 경우
|
||||
권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.6`이다.
|
||||
[소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는 GitHub에서 찾을 수 있다.
|
||||
|
||||
Microsoft는 리눅스 및 윈도우 amd64를 지원하는 다중 아키텍처 이미지를
|
||||
`mcr.microsoft.com/oss/kubernetes/pause:3.6`에서 유지보수하고 있다.
|
||||
이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만,
|
||||
모든 윈도우 바이너리가 Microsoft에 의해
|
||||
[인증 코드(authenticode)로 서명](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)되었다.
|
||||
서명된 바이너리를 필요로 하는 프로덕션 또는 프로덕션에 준하는 환경에 파드를 배포하는 경우,
|
||||
Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다.
|
||||
|
||||
## 컨테이너 런타임 {#container-runtime}
|
||||
|
||||
파드가 각 노드에서 실행될 수 있도록,
|
||||
클러스터의 각 노드에 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
|
||||
설치해야 한다.
|
||||
|
||||
다음 컨테이너 런타임은 윈도우에서 동작한다.
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
### ContainerD
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
|
||||
|
||||
{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+를
|
||||
윈도우 노드의 컨테이너 런타임으로 사용할 수 있다.
|
||||
|
||||
[윈도우 노드에 ContainerD를 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치)하는 방법을 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
containerd와 GMSA 사용 시 윈도우 네트워크 공유 접근에 대한
|
||||
[알려진 제한](/ko/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있으며,
|
||||
이는 커널 패치를 필요로 한다.
|
||||
{{< /note >}}
|
||||
|
||||
### Mirantis Container Runtime {#mcr}
|
||||
|
||||
[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은
|
||||
Windows Server 2019 및 이후 버전을 지원하는 컨테이너 런타임이다.
|
||||
|
||||
더 많은 정보는 [Windows Server에 MCR 설치하기](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html)를 참고한다.
|
||||
|
||||
## 윈도우 운영 체제 버전 호환성 {#windows-os-version-support}
|
||||
|
||||
윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 한다는
|
||||
엄격한 호환성 규칙이 있다.
|
||||
컨테이너 운영 체제가 Windows Server 2019인 윈도우 컨테이너만이 완전히 지원된다.
|
||||
|
||||
쿠버네티스 v{{< skew currentVersion >}}에서,
|
||||
윈도우 노드(및 파드)에 대한 운영 체제 호환성은 다음과 같다.
|
||||
|
||||
Windows Server LTSC 릴리스
|
||||
: Windows Server 2019
|
||||
: Windows Server 2022
|
||||
|
||||
Windows Server SAC 릴리스
|
||||
: Windows Server 버전 20H2
|
||||
|
||||
쿠버네티스 [버전 차이 정책](/ko/releases/version-skew-policy/) 또한 적용된다.
|
||||
|
||||
## 도움 받기 및 트러블슈팅 {#troubleshooting}
|
||||
|
||||
쿠버네티스 클러스터 트러블슈팅을 위한
|
||||
기본 도움말은 [이 섹션](/ko/docs/tasks/debug/)을
|
||||
먼저 찾아 본다.
|
||||
|
||||
이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다.
|
||||
로그는 쿠버네티스에서 트러블슈팅하는 데 중요한 요소이다.
|
||||
다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함시켜야 한다.
|
||||
SIG Windows의
|
||||
[로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의
|
||||
지침을 따른다.
|
||||
|
||||
### 이슈 리포팅 및 기능 요청
|
||||
|
||||
버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면,
|
||||
[SIG Windows 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#reporting-issues-and-feature-requests)를 참고하여
|
||||
새 이슈를 연다. 먼저 이전에 이미 보고된 이슈가 있는지 검색하고,
|
||||
이슈에 대한 경험과 추가 로그를 기재해야 한다.
|
||||
티켓을 만들기 전에, 쿠버네티스 슬랙의 SIG Windows 채널 또한
|
||||
초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 곳이다.
|
||||
|
||||
## 배포 도구
|
||||
|
||||
kubeadm 도구는 클러스터를 관리할 컨트롤 플레인과 워크로드를 실행할 노드를 제공함으로써
|
||||
쿠버네티스 클러스터를 배포할 수 있게 해 준다.
|
||||
[윈도우 노드 추가하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 문서에서
|
||||
kubeadm을 사용해 어떻게 클러스터에 윈도우 노드를 배포하는지를 설명한다.
|
||||
|
||||
쿠버네티스 [클러스터 API](https://cluster-api.sigs.k8s.io/) 프로젝트는 윈도우 노드 배포를 자동화하는 수단을 제공한다.
|
||||
|
||||
## 윈도우 배포 채널
|
||||
|
||||
윈도우 배포 채널에 대한 자세한 설명은
|
||||
[Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다.
|
||||
|
||||
각각의 Windows Server 서비스 채널 및 지원 모델은
|
||||
[Windows Server 서비스 채널](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison)에서
|
||||
확인할 수 있다.
|
||||
|
|
@ -1,9 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - jayunit100
|
||||
# - jsturtevant
|
||||
# - marosset
|
||||
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
|
||||
content_type: concept
|
||||
weight: 75
|
||||
|
|
@ -14,29 +13,27 @@ weight: 75
|
|||
많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다.
|
||||
이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 목표
|
||||
|
||||
* 윈도우 노드에서 윈도우 컨테이너를 실행하는 예시 디플로이먼트를 구성한다.
|
||||
* (선택) 그룹 매니지드 서비스 어카운트(GMSA)를 이용한 사용자 파드를 위한 액티브 디렉터리 신원(Active Directory Identity)을 구성한다.
|
||||
* 쿠버네티스의 윈도우 관련 기능을 강조한다.
|
||||
|
||||
## 시작하기 전에
|
||||
|
||||
* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
|
||||
포함하는 쿠버네티스 클러스터를 생성한다.
|
||||
* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)를
|
||||
포함하는 쿠버네티스 클러스터를 생성한다.
|
||||
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
|
||||
모두 비슷한 방식이라는 것이 중요하다.
|
||||
[Kubectl 커맨드](/ko/docs/reference/kubectl/)로 클러스터에 접속하는 것은 동일하다.
|
||||
아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
|
||||
모두 비슷한 방식이라는 것이 중요하다.
|
||||
[kubectl 커맨드](/ko/docs/reference/kubectl/)로 클러스터에 접속하는 것은 동일하다.
|
||||
아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
|
||||
|
||||
## 시작하기: 윈도우 컨테이너 배포하기
|
||||
|
||||
쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다.
|
||||
아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다.
|
||||
아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자.
|
||||
아래 예시 YAML 파일은 윈도우 컨테이너 안에서 실행되는 간단한 웹서버 애플리케이션을 배포한다.
|
||||
|
||||
아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`이라는 이름으로 생성한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -47,7 +44,7 @@ metadata:
|
|||
app: win-webserver
|
||||
spec:
|
||||
ports:
|
||||
# 이 서비스에서 제공하는 포트
|
||||
# 이 서비스가 서비스를 제공할 포트
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
selector:
|
||||
|
|
@ -83,8 +80,8 @@ spec:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
포트 매핑도 지원하지만, 간략한 예시를 위해
|
||||
컨테이너 포트 80을 직접 서비스로 노출한다.
|
||||
포트 매핑도 지원하지만, 이 예시에서는 간결성을 위해
|
||||
컨테이너 포트 80을 서비스로 직접 노출한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 모든 노드가 건강한지 확인한다.
|
||||
|
|
@ -104,7 +101,6 @@ spec:
|
|||
|
||||
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
|
||||
|
||||
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
|
||||
* 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
|
||||
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
|
||||
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
|
||||
|
|
@ -139,16 +135,17 @@ LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플
|
|||
LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고,
|
||||
LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다.
|
||||
|
||||
## 설정 가능한 컨테이너 username 사용하기
|
||||
## 컨테이너 사용자 구성하기
|
||||
|
||||
쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를
|
||||
실행하도록 설정할 수 있다.
|
||||
이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다.
|
||||
### 설정 가능한 컨테이너 username 사용하기
|
||||
|
||||
윈도우 컨테이너는 이미지 기본값과는 다른 username으로
|
||||
엔트리포인트와 프로세스를 실행하도록 설정할 수 있다.
|
||||
[여기](/ko/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다.
|
||||
|
||||
## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
|
||||
### 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
|
||||
|
||||
쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다.
|
||||
윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다.
|
||||
그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능,
|
||||
단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다.
|
||||
GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다.
|
||||
|
|
@ -156,12 +153,11 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
|
|||
|
||||
## 테인트(Taint)와 톨러레이션(Toleration)
|
||||
|
||||
오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와
|
||||
노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
|
||||
이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
|
||||
사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 스케줄링되도록 하기 위해
|
||||
테인트와 노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
|
||||
아래는 권장되는 방식의 개요인데,
|
||||
이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
|
||||
|
||||
|
||||
`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면,
|
||||
파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다).
|
||||
리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다.
|
||||
|
|
@ -179,8 +175,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
|
|||
일반적인 쿠버네티스 메카니즘을 사용해야 한다.
|
||||
|
||||
`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에,
|
||||
윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트,
|
||||
톨러레이션 및 노드 셀렉터가 여전히 필요하다.
|
||||
윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면
|
||||
테인트, 톨러레이션 및 노드 셀렉터가 여전히 필요하다.
|
||||
|
||||
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
|
||||
|
||||
|
|
@ -231,17 +227,15 @@ tolerations:
|
|||
|
||||
| 제품 이름 | 빌드 번호 |
|
||||
|--------------------------------------|------------------------|
|
||||
| 윈도우 서버 2019 | 10.0.17763 |
|
||||
| 윈도우 서버 버전 1809 | 10.0.17763 |
|
||||
| 윈도우 서버 버전 1903 | 10.0.18362 |
|
||||
|
||||
| Windows Server 2019 | 10.0.17763 |
|
||||
| Windows Server, 버전 20H2 | 10.0.19042 |
|
||||
| Windows Server 2022 | 10.0.20348 |
|
||||
|
||||
### RuntimeClass로 단순화
|
||||
|
||||
[런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다.
|
||||
클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다.
|
||||
|
||||
|
||||
1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS,
|
||||
아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되어 있다.
|
||||
|
||||
|
|
@ -263,8 +257,8 @@ scheduling:
|
|||
value: "windows"
|
||||
```
|
||||
|
||||
2. 클러스터 관리자로 `kubectl create -f runtimeClasses.yml` 를 실행해서 사용한다.
|
||||
3. 파드 사양에 적합한 `runtimeClassName: windows-2019` 를 추가한다.
|
||||
1. 클러스터 관리자로 `kubectl create -f runtimeClasses.yml` 를 실행해서 사용한다.
|
||||
1. 파드 사양에 적합한 `runtimeClassName: windows-2019` 를 추가한다.
|
||||
|
||||
예시:
|
||||
|
||||
|
|
@ -313,7 +307,4 @@ spec:
|
|||
app: iis-2019
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/ko/docs/concepts/containers/runtime-class/
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - soltysh
|
||||
title: 잡
|
||||
content_type: concept
|
||||
feature:
|
||||
title: 배치 실행
|
||||
description: >
|
||||
쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다.
|
||||
쿠버네티스는 서비스 외에도 배치(batch)와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다.
|
||||
weight: 50
|
||||
---
|
||||
|
||||
|
|
@ -51,13 +51,8 @@ job.batch/pi created
|
|||
|
||||
`kubectl` 을 사용해서 잡 상태를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl describe jobs/pi
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
{{< tabs name="Check status of Job" >}}
|
||||
{{< tab name="kubectl describe job pi" codelang="bash" >}}
|
||||
Name: pi
|
||||
Namespace: default
|
||||
Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
|
||||
|
|
@ -91,7 +86,62 @@ Events:
|
|||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7
|
||||
```
|
||||
{{< /tab >}}
|
||||
{{< tab name="kubectl get job pi -o yaml" codelang="bash" >}}
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
annotations:
|
||||
kubectl.kubernetes.io/last-applied-configuration: |
|
||||
{"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":{"spec":{"containers":[{"command":["perl","-Mbignum=bpi","-wle","print bpi(2000)"],"image":"perl","name":"pi"}],"restartPolicy":"Never"}}}}
|
||||
creationTimestamp: "2022-06-15T08:40:15Z"
|
||||
generation: 1
|
||||
labels:
|
||||
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
|
||||
job-name: pi
|
||||
name: pi
|
||||
namespace: default
|
||||
resourceVersion: "987"
|
||||
uid: 863452e6-270d-420e-9b94-53a54146c223
|
||||
spec:
|
||||
backoffLimit: 4
|
||||
completionMode: NonIndexed
|
||||
completions: 1
|
||||
parallelism: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
|
||||
suspend: false
|
||||
template:
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
labels:
|
||||
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
|
||||
job-name: pi
|
||||
spec:
|
||||
containers:
|
||||
- command:
|
||||
- perl
|
||||
- -Mbignum=bpi
|
||||
- -wle
|
||||
- print bpi(2000)
|
||||
image: perl
|
||||
imagePullPolicy: Always
|
||||
name: pi
|
||||
resources: {}
|
||||
terminationMessagePath: /dev/termination-log
|
||||
terminationMessagePolicy: File
|
||||
dnsPolicy: ClusterFirst
|
||||
restartPolicy: Never
|
||||
schedulerName: default-scheduler
|
||||
securityContext: {}
|
||||
terminationGracePeriodSeconds: 30
|
||||
status:
|
||||
active: 1
|
||||
ready: 1
|
||||
startTime: "2022-06-15T08:40:15Z"
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
`kubectl get pods` 를 사용해서 잡의 완료된 파드를 본다.
|
||||
|
||||
|
|
@ -119,7 +169,7 @@ kubectl logs $pods
|
|||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
```
|
||||
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
|
||||
```
|
||||
|
||||
|
|
@ -248,14 +298,24 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
|
|||
|
||||
### 파드 백오프(backoff) 실패 정책
|
||||
|
||||
구성 등의 논리적 오류로 인해 약간의 재시도 이후에
|
||||
잡을 실패하게 만들려는 경우가 있다.
|
||||
이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에
|
||||
재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과
|
||||
관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...)
|
||||
한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나
|
||||
해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
|
||||
카운트가 재설정된다.
|
||||
구성에 논리적 오류가 포함되어 있어서 몇 회의 재시도 이후에
|
||||
잡이 실패되도록 만들어야 하는 경우가 있다.
|
||||
이렇게 하려면 `.spec.backoffLimit`의 값에
|
||||
재시도(잡을 실패로 처리하기 이전까지) 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다.
|
||||
잡에 연계된 실패 상태 파드는 6분 내에서 지수적으로 증가하는
|
||||
백-오프 지연(10초, 20초, 40초 ...)을 적용하여, 잡 컨트롤러에 의해 재생성된다.
|
||||
|
||||
재시도 횟수는 다음 두 가지 방법으로 계산된다.
|
||||
- `.status.phase = "Failed"`인 파드의 수.
|
||||
- `restartPolicy = "OnFailure"`를 사용하는 경우, `.status.phase`가
|
||||
`Pending`이거나 `Running`인 파드들이 가지고 있는 모든 컨테이너의 수.
|
||||
|
||||
계산 중 하나가 `.spec.backoffLimit`에 도달하면, 잡이
|
||||
실패한 것으로 간주한다.
|
||||
|
||||
[`JobTrackingWithFinalizers`](#종료자-finalizers-를-이용한-잡-추적) 기능이 비활성화되어
|
||||
있다면, 실패한 파드의 수는 API에 여전히 표시되고 있는 파드로만
|
||||
계산된다.
|
||||
|
||||
{{< note >}}
|
||||
만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
|
||||
|
|
@ -631,7 +691,6 @@ spec:
|
|||
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와
|
||||
[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해
|
||||
`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
기본적으로는 활성화되어 있다.
|
||||
|
||||
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
|
||||
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
#reviewers:
|
||||
#- Kashomon
|
||||
#- bprashanth
|
||||
#- madhusudancs
|
||||
title: 레플리카셋
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -78,7 +78,7 @@ kubectl describe rs/frontend
|
|||
|
||||
출력은 다음과 유사할 것이다.
|
||||
|
||||
```shell
|
||||
```
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
Selector: tier=frontend
|
||||
|
|
@ -130,7 +130,7 @@ kubectl get pods frontend-b2zdv -o yaml
|
|||
|
||||
메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
@ -181,7 +181,7 @@ kubectl get pods
|
|||
|
||||
결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-b2zdv 1/1 Running 0 10m
|
||||
frontend-vcmts 1/1 Running 0 10m
|
||||
|
|
@ -210,7 +210,7 @@ kubectl get pods
|
|||
```
|
||||
|
||||
다음 출력에서 볼 수 있다.
|
||||
```shell
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-hmmj2 1/1 Running 0 9s
|
||||
pod1 1/1 Running 0 36s
|
||||
|
|
@ -387,7 +387,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
|
|||
|
||||
### 기본 파드
|
||||
|
||||
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 어떤 에이전트에게 위임한다(예를들어 Kubelet 또는 도커).
|
||||
사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 Kubelet과 같은 에이전트에게 위임한다.
|
||||
|
||||
### 잡
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 40
|
|||
|
||||
<!-- overview -->
|
||||
이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}}의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}}의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이다. 초기화 컨테이너는 앱 이미지에는 없는
|
||||
유틸리티 또는 설정 스크립트 등을 포함할 수 있다.
|
||||
|
||||
초기화 컨테이너는 `containers` 배열(앱 컨테이너를 기술하는)과 나란히
|
||||
|
|
@ -333,3 +333,4 @@ Active deadline은 초기화 컨테이너를 포함한다.
|
|||
|
||||
* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
|
||||
* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug/debug-application/debug-init-containers/) 알아보기
|
||||
|
||||
|
|
|
|||
|
|
@ -4,14 +4,14 @@ content_type: concept
|
|||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
|
||||
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 {{< glossary_tooltip text="파드" term_id="Pod" >}}가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
## 필수 구성 요소
|
||||
|
||||
### 노드 레이블
|
||||
|
|
@ -64,6 +64,7 @@ metadata:
|
|||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: <integer>
|
||||
minDomains: <integer>
|
||||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
|
|
@ -76,30 +77,30 @@ spec:
|
|||
|
||||
- `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
|
||||
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
|
||||
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수.
|
||||
예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면,
|
||||
전역 최솟값은 0)
|
||||
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수.
|
||||
예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면,
|
||||
전역 최솟값은 0)
|
||||
사이에 허용되는 최대 차이이다.
|
||||
- `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
|
||||
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
|
||||
|
||||
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다.
|
||||
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
|
||||
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다.
|
||||
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
|
||||
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
|
||||
|
||||
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
|
||||
파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다.
|
||||
"글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며,
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
|
||||
파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다.
|
||||
"글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며,
|
||||
적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
|
||||
이 값은 스케줄링에 영향을 미치지 않는다.
|
||||
- `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다.
|
||||
- `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다.
|
||||
|
||||
{{< note >}}
|
||||
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
|
||||
이를 사용하려면 `MinDomainsInPodToplogySpread`
|
||||
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
|
||||
이를 사용하려면 `MinDomainsInPodToplogySpread`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -190,7 +191,7 @@ graph BT
|
|||
|
||||
- `maxSkew` 를 "2" 보다 큰 값으로 변경해서 들어오는 파드들이 "zoneA"에도 배치할 수 있도록 한다.
|
||||
- `topologyKey` 를 "node"로 변경해서 파드가 영역이 아닌, 노드에 걸쳐 고르게 분산할 수 있게 한다. 위의 예시에서 만약 `maxSkew` 가 "1"로 유지되면 들어오는 파드는 오직 "node4"에만 배치할 수 있다.
|
||||
- `whenUnsatisfiable: DoNotSchedule` 에서 `whenUnsatisfiable: ScheduleAnyway` 로 변경하면 들어오는 파드는 항상 다른 스케줄링 API를 충족한다는 가정하에 스케줄할 수 있도록 보장한다. 그러나 일치하는 파드가 적은 토폴로지 도메인에 배치되는 것이 좋다. (이 선호도는 리소스 사용 비율 등과 같은 다른 내부 스케줄링 우선순위와 공동으로 정규화 된다는 것을 알아두자.)
|
||||
- `whenUnsatisfiable: DoNotSchedule` 에서 `whenUnsatisfiable: ScheduleAnyway` 로 변경하면 들어오는 파드는 항상 다른 스케줄링 API를 충족한다는 가정하에 스케줄할 수 있도록 보장한다. 그러나 일치하는 파드가 적은 토폴로지 도메인에 배치되는 것이 좋다. (이 선호도는 리소스 사용 비율 등과 같은 다른 내부 스케줄링 우선순위와 공동으로 정규화 된다는 것을 알아두자.)
|
||||
|
||||
### 예시: 다중 토폴로지 분배 제약 조건
|
||||
|
||||
|
|
@ -338,8 +339,8 @@ profiles:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
|
||||
기본적으로 비활성화되어 있다.
|
||||
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
|
||||
기본적으로 비활성화되어 있다.
|
||||
비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -347,7 +348,7 @@ profiles:
|
|||
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
|
||||
파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
|
||||
kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -365,8 +366,8 @@ defaultConstraints:
|
|||
|
||||
{{< note >}}
|
||||
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
|
||||
없는 노드에 점수를 매기지 않는다.
|
||||
이로 인해 기본 토폴로지 제약을 사용하는 경우의
|
||||
없는 노드에 점수를 매기지 않는다.
|
||||
이로 인해 기본 토폴로지 제약을 사용하는 경우의
|
||||
레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
|
||||
|
||||
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
|
||||
|
|
@ -411,7 +412,7 @@ profiles:
|
|||
## 알려진 제한사항
|
||||
|
||||
- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다. 예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다.
|
||||
[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다.
|
||||
[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다.
|
||||
- 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -18,8 +18,15 @@ card:
|
|||
{{< note >}}
|
||||
일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은
|
||||
[기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다.
|
||||
|
||||
또한, 쿠버네티스 기여에 대한 내용은
|
||||
{{< glossary_tooltip text="CNCF" term_id="cncf" >}}
|
||||
[문서](https://contribute.cncf.io/contributors/projects/#kubernetes)
|
||||
를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
---
|
||||
|
||||
이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다.
|
||||
|
||||
쿠버네티스 문서 기여자들은
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ SIG Docs의 공동 의장 역할을 할 수 있다.
|
|||
다음과 같은 책임을 가진다.
|
||||
|
||||
- SIG Docs가 우수한 문서화를 통해 개발자의 행복을 극대화하는 데 집중한다.
|
||||
- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다.
|
||||
- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다.
|
||||
- 기여에 대한 새로운 지침을 확인하여 SIG에 대한 모범 사례를 배우고 설정한다.
|
||||
- SIG 회의를 예약하고 진행한다. 주간 상태 업데이트, 브랜치별 회고/기획 세션과 필요에 따라 그 외 세션을 진행한다.
|
||||
- KubeCon 이벤트 및 기타 컨퍼런스에서 문서 스프린트를 스케줄링하고 진행한다.
|
||||
|
|
|
|||
|
|
@ -43,10 +43,10 @@ class S,T spacewhite
|
|||
class first,second white
|
||||
{{</ mermaid >}}
|
||||
|
||||
***Figure - Contributing new content preparation***
|
||||
***그림 - 새로운 콘텐츠 기여를 위한 준비***
|
||||
|
||||
The figure above depicts the information you should know
|
||||
prior to submitting new content. The information details follow.
|
||||
위 그림은 새로운 콘텐츠를 제출하기 전에 알아야 할 정보를 설명한다.
|
||||
해당 정보에 대한 자세한 내용은 다음과 같다.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,13 +15,15 @@ card:
|
|||
[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
|
||||
|
||||
변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
|
||||
|
||||
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다.
|
||||
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다.
|
||||
[시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의
|
||||
모든 요구 사항을 준수해야 한다.
|
||||
|
||||
변경 사항이 적거나, git에 익숙하지 않은 경우,
|
||||
[GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
|
||||
|
||||
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고
|
||||
컴퓨터에서 로컬로 변경하는 방법을 배운다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -61,7 +63,7 @@ class tasks,tasks2 white
|
|||
class id1 k8s
|
||||
{{</ mermaid >}}
|
||||
|
||||
***그림 - GitHub 상에서 PR을 여는 단계***
|
||||
그림 - GitHub 상에서 PR을 여는 단계
|
||||
|
||||
1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
|
||||
페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
|
||||
|
|
@ -91,7 +93,8 @@ class id1 k8s
|
|||
- **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다.
|
||||
|
||||
{{< note >}}
|
||||
PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
|
||||
PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다.
|
||||
자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
|
||||
{{</ note >}}
|
||||
|
||||
7. **Create pull request** 를 선택한다.
|
||||
|
|
@ -120,7 +123,8 @@ GitHub 사용자 이름을 코멘트로 남긴다.
|
|||
git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
|
||||
로컬 포크로 작업한다.
|
||||
|
||||
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
|
||||
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다.
|
||||
git UI 애플리케이션을 사용할 수도 있다.
|
||||
|
||||
아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
|
||||
|
||||
|
|
@ -151,7 +155,8 @@ class 1,2,3,3a,4,5,6 grey
|
|||
class S,T spacewhite
|
||||
class changes,changes2 white
|
||||
{{</ mermaid >}}
|
||||
***그림 - 로컬 포크에서 변경 사항 작업하기***
|
||||
|
||||
그림 - 로컬 포크에서 변경 사항 작업하기
|
||||
|
||||
### kubernetes/website 리포지터리 포크하기
|
||||
|
||||
|
|
@ -201,7 +206,10 @@ class changes,changes2 white
|
|||
이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
|
||||
이 워크플로는
|
||||
[쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)
|
||||
와 다르다.
|
||||
포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
|
||||
{{< /note >}}
|
||||
|
||||
### 브랜치 만들기
|
||||
|
|
@ -211,14 +219,16 @@ class changes,changes2 white
|
|||
- 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
|
||||
- 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
|
||||
- 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
|
||||
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
||||
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다.
|
||||
자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
||||
- 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
|
||||
해당 작업을 위해 작성된 특정 기능 브랜치를
|
||||
사용한다.
|
||||
|
||||
브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
|
||||
|
||||
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
|
||||
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다.
|
||||
이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
|
||||
|
||||
```bash
|
||||
git checkout -b <my_new_branch> upstream/main
|
||||
|
|
@ -268,7 +278,8 @@ class changes,changes2 white
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할
|
||||
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자.
|
||||
나중에 풀 리퀘스트 설명에 추가할
|
||||
수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -280,39 +291,34 @@ class changes,changes2 white
|
|||
|
||||
### 로컬에서 변경 사항 미리보기 {#preview-locally}
|
||||
|
||||
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
|
||||
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다.
|
||||
미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
|
||||
|
||||
website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
|
||||
website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다.
|
||||
도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로,
|
||||
디버깅에 유용할 수 있다.
|
||||
|
||||
{{< tabs name="tab_with_hugo" >}}
|
||||
{{% tab name="Hugo 컨테이너" %}}
|
||||
|
||||
{{< note >}}
|
||||
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
|
||||
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다.
|
||||
이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 로컬에서 이미지를 빌드한다.
|
||||
_Hugo 도구 자체에 대한 변경을 테스트하는 경우에만 이 단계가 필요하다._
|
||||
|
||||
```bash
|
||||
# docker 사용(기본값)
|
||||
make container-image
|
||||
|
||||
### 또는 ###
|
||||
|
||||
# podman 사용
|
||||
CONTAINER_ENGINE=podman make container-image
|
||||
```shell
|
||||
# 터미널에서 명령 실행 (필요에 따라)
|
||||
make container-serve
|
||||
```
|
||||
|
||||
2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
|
||||
2. 컨테이너에서 Hugo를 시작한다.
|
||||
|
||||
```bash
|
||||
# docker 사용(기본값)
|
||||
```shell
|
||||
# 터미널에서 실행
|
||||
make container-serve
|
||||
|
||||
### 또는 ###
|
||||
|
||||
# podman 사용
|
||||
CONTAINER_ENGINE=podman make container-serve
|
||||
```
|
||||
|
||||
3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는
|
||||
|
|
@ -326,18 +332,19 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
|
|||
|
||||
또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
|
||||
|
||||
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
|
||||
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된
|
||||
[Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
|
||||
|
||||
2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
|
||||
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
|
||||
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git submodule update --init --recursive --depth 1
|
||||
```
|
||||
|
||||
3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
cd <path_to_your_repo>/website
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
|
@ -354,6 +361,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
|
|||
### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
|
||||
|
||||
아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
||||
|
|
@ -379,7 +387,8 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b
|
|||
class 1,2,3,4,5,6,7,8 grey
|
||||
class first,second white
|
||||
{{</ mermaid >}}
|
||||
***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
|
||||
|
||||
그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계
|
||||
|
||||
1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
|
||||
2. **New Pull Request** 를 선택한다.
|
||||
|
|
@ -387,29 +396,36 @@ class first,second white
|
|||
4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다.
|
||||
5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다.
|
||||
6. **Create Pull Request** 를 선택한다.
|
||||
7. 풀 리퀘스트에 대한 설명을 추가한다.
|
||||
`. 풀 리퀘스트에 대한 설명을 추가한다.
|
||||
|
||||
- **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다.
|
||||
- **Description**: 변경 사항을 자세히 설명한다.
|
||||
- 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
|
||||
- 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
|
||||
|
||||
8. **Create pull request** 버튼을 선택한다.
|
||||
- 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다.
|
||||
이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다.
|
||||
다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
|
||||
- 구체적인 내용에 대한 조언이 필요한 경우,
|
||||
원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
|
||||
|
||||
7. **Create pull request** 버튼을 선택한다.
|
||||
|
||||
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
|
||||
|
||||
|
||||
PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
|
||||
PR을 연 후, GitHub는 자동 테스트를 실행하고
|
||||
[Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
|
||||
|
||||
- Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다.
|
||||
- Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
|
||||
- Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기
|
||||
직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
|
||||
|
||||
또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
|
||||
또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다.
|
||||
자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
|
||||
|
||||
### 로컬에서 피드백 해결
|
||||
|
||||
1. 변경한 후, 이전 커밋을 수정한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git commit -a --amend
|
||||
```
|
||||
|
||||
|
|
@ -421,7 +437,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
3. `git push origin <my_new_branch>` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다.
|
||||
|
||||
{{< note >}}
|
||||
수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
|
||||
수정하는 대신 `git commit -m` 을 사용하는 경우,
|
||||
병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 리뷰어의 변경
|
||||
|
|
@ -430,35 +447,38 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
|
||||
1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git fetch origin
|
||||
git rebase origin/<your-branch-name>
|
||||
```
|
||||
|
||||
2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
#### 충돌 병합 및 리베이스
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts),
|
||||
[고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나,
|
||||
슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
{{< /note >}}
|
||||
|
||||
다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다.
|
||||
다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다.
|
||||
PR의 모든 병합 충돌을 해결해야 한다.
|
||||
|
||||
1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git fetch origin
|
||||
git rebase origin/<your-branch-name>
|
||||
```
|
||||
|
||||
그런 다음 포크에 변경 사항을 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
|
|
@ -477,7 +497,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
|
||||
이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다.
|
||||
|
||||
4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다.
|
||||
4. 충돌한 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다.
|
||||
충돌을 해결하고 충돌 마커를 삭제한다.
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다.
|
||||
|
|
@ -485,12 +506,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
|
||||
5. 변경 세트에 파일을 추가한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git add <filename>
|
||||
```
|
||||
|
||||
6. 리베이스를 계속한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
|
|
@ -500,7 +522,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
|
||||
8. 브랜치를 포크에 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
|
|
@ -509,10 +531,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|||
### 커밋 스쿼시하기
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나,
|
||||
슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
{{< /note >}}
|
||||
|
||||
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다.
|
||||
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다.
|
||||
PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여
|
||||
커밋 수를 확인할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다.
|
||||
|
|
@ -520,15 +545,16 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|||
|
||||
1. 대화식 리베이스를 시작한다.
|
||||
|
||||
```bash
|
||||
```shell
|
||||
git rebase -i HEAD~<number_of_commits_in_branch>
|
||||
```
|
||||
|
||||
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
|
||||
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다.
|
||||
`HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```bash
|
||||
```none
|
||||
pick d875112ca Original commit
|
||||
pick 4fa167b80 Address feedback 1
|
||||
pick 7d54e15ee Address feedback 2
|
||||
|
|
@ -540,7 +566,9 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|||
# 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다.
|
||||
```
|
||||
|
||||
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
|
||||
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다.
|
||||
두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다.
|
||||
`pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
|
||||
|
||||
리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다.
|
||||
|
||||
|
|
@ -552,7 +580,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|||
|
||||
다음의 원본 텍스트를 변경한다.
|
||||
|
||||
```bash
|
||||
```none
|
||||
pick d875112ca Original commit
|
||||
pick 4fa167b80 Address feedback 1
|
||||
pick 7d54e15ee Address feedback 2
|
||||
|
|
@ -560,13 +588,14 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|||
|
||||
아래와 같이 변경한다.
|
||||
|
||||
```bash
|
||||
```none
|
||||
pick d875112ca Original commit
|
||||
squash 4fa167b80 Address feedback 1
|
||||
squash 7d54e15ee Address feedback 2
|
||||
```
|
||||
|
||||
이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
|
||||
이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다.
|
||||
타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
|
||||
|
||||
3. 파일을 저장하고 종료한다.
|
||||
|
||||
|
|
@ -578,14 +607,15 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|||
|
||||
## 다른 리포지터리에 기여하기
|
||||
|
||||
[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다.
|
||||
[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다.
|
||||
이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스
|
||||
또는 코드 주석과 같은 문서가 포함되어 있다.
|
||||
|
||||
개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다.
|
||||
이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다.
|
||||
|
||||
각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를
|
||||
제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고
|
||||
`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
|
||||
각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 제기하거나 PR을 제출하기 전에,
|
||||
그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 `code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
|
||||
|
||||
대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한
|
||||
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
|
||||
|
|
|
|||
|
|
@ -93,9 +93,8 @@ PR 소유자에게 조언하는데 활용된다.
|
|||
|
||||
## 병합 작업 방식
|
||||
|
||||
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
|
||||
브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의
|
||||
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
|
||||
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다.
|
||||
게시된 콘텐츠의 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
|
||||
작동 방식은 다음과 같다.
|
||||
|
||||
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
|
|||
- [슬랙](https://slack.k8s.io/) 또는
|
||||
[SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
|
||||
|
||||
[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
|
||||
[CLA에 서명](https://github.com/kubernetes/community/blob/master/CLA.md) 후에 누구나 다음을 할 수 있다.
|
||||
|
||||
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
|
||||
- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.
|
||||
|
|
|
|||
|
|
@ -181,7 +181,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의
|
|||
|
||||
### 블로그 이슈
|
||||
|
||||
[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라
|
||||
[쿠버네티스 블로그](/blog/) 항목은 시간이 지남에 따라
|
||||
구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다.
|
||||
1년이 지난 블로그 항목과 관련된 이슈일 경우,
|
||||
수정하지 않고 이슈를 닫는다.
|
||||
|
|
@ -221,3 +221,5 @@ https://github.com/kubernetes/kubernetes 에서
|
|||
|
||||
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 풀 리퀘스트 리뷰
|
||||
title: 풀 리퀘스트 리뷰하기
|
||||
content_type: concept
|
||||
main_menu: true
|
||||
weight: 10
|
||||
|
|
@ -7,7 +7,8 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다.
|
||||
누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다.
|
||||
쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다.
|
||||
|
||||
문서화에 대한 풀 리퀘스트를 리뷰하는 것은
|
||||
쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다.
|
||||
|
|
@ -18,7 +19,7 @@ weight: 10
|
|||
- 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
|
||||
[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
|
||||
- 쿠버네티스 문서화 커뮤니티의 다양한
|
||||
[역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을
|
||||
[역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을
|
||||
이해한다.
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -27,7 +28,9 @@ weight: 10
|
|||
|
||||
리뷰를 시작하기 전에 다음을 명심하자.
|
||||
|
||||
- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 항상 준수한다.
|
||||
|
||||
- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고
|
||||
항상 준수한다.
|
||||
- 정중하고, 사려 깊고, 도움이 되자.
|
||||
- PR의 긍정적인 측면과 변화에 대한 의견을 남긴다.
|
||||
- 당신의 리뷰를 어떻게 받아들일지에 대해 공감하고 주의한다.
|
||||
|
|
@ -36,7 +39,8 @@ weight: 10
|
|||
|
||||
## 리뷰 과정
|
||||
|
||||
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
|
||||
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다.
|
||||
각 단계에 대한 상세 사항은 아래에 나와 있다.
|
||||
|
||||
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
||||
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
||||
|
|
@ -54,10 +58,10 @@ flowchart LR
|
|||
T[ ] -.-
|
||||
J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로<br>변경사항 미리보기]
|
||||
end
|
||||
|
||||
|
||||
A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여<br>PR을 필터링]
|
||||
B --> third --> fourth
|
||||
|
||||
|
||||
|
||||
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
|
||||
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
|
||||
|
|
@ -69,32 +73,39 @@ class third,fourth white
|
|||
|
||||
그림 1. 리뷰 과정 절차.
|
||||
|
||||
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
|
||||
이동한다.
|
||||
쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이
|
||||
표시된다.
|
||||
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다.
|
||||
쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 표시된다.
|
||||
|
||||
2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다.
|
||||
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다.
|
||||
|
||||
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다.
|
||||
자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을
|
||||
참고한다.
|
||||
- `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다.
|
||||
- `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.
|
||||
|
||||
또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다.
|
||||
또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다.
|
||||
`work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다.
|
||||
|
||||
3. 리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다.
|
||||
|
||||
- PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
|
||||
- 다른 리뷰어의 의견 읽기
|
||||
- **Files changed** 탭을 클릭하여 변경된 파일과 행 보기
|
||||
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 Netlify 미리보기 빌드의 변경 사항을 확인.
|
||||
다음은 스크린샷이다(GitHub 데스크탑 사이트이며,
|
||||
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여
|
||||
Netlify 미리보기 빌드의 변경 사항을 확인.
|
||||
다음은 스크린샷이다(GitHub 데스크탑 사이트이며,
|
||||
태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다).
|
||||
{{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="Netlify 미리보기 링크를 포함하는 GitHub PR 상세 사항" >}}
|
||||
미리보기를 열려면, 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다.
|
||||
미리보기를 열려면,
|
||||
체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다.
|
||||
|
||||
4. **Files changed** 탭으로 이동하여 리뷰를 시작한다.
|
||||
|
||||
1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.
|
||||
2. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다.
|
||||
3. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서
|
||||
1. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우)
|
||||
또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다.
|
||||
1. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서
|
||||
리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!),
|
||||
PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는
|
||||
항상 **Comment** 를 선택해야 한다.
|
||||
|
|
@ -119,13 +130,21 @@ class third,fourth white
|
|||
|
||||
### 웹 사이트
|
||||
|
||||
- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가?
|
||||
- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가?
|
||||
그렇다면, 이 PR의 결과로 끊어진 링크가 있는가?
|
||||
slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가?
|
||||
|
||||
- PR이 새로운 페이지를 소개하는가? 그렇다면,
|
||||
- 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가?
|
||||
|
||||
- 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과
|
||||
연관된 Hugo 단축 코드를 사용하는가?
|
||||
- 섹션의 측면 탐색에 페이지가 올바르게 나타나는가?
|
||||
- 페이지가 [문서 홈](/docs/home/) 목록에 나타나야 하는가?
|
||||
- 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다.
|
||||
|
||||
- 변경 사항이 Netlify 미리보기에 표시되는가?
|
||||
목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다.
|
||||
|
||||
### 기타
|
||||
|
||||
오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다.
|
||||
오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다.
|
||||
이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: 콘텐츠 개선 제안
|
||||
slug: suggest-improvements
|
||||
title: 콘텐츠 개선 제안하기
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
|
|
|
|||
|
|
@ -8,5 +8,10 @@ card:
|
|||
title: 사용 가능한 문서 버전
|
||||
---
|
||||
|
||||
이 웹사이트에서는 쿠버네티스 최신 버전 및
|
||||
이 웹사이트에서는 쿠버네티스 현재 버전 및
|
||||
이전 4개 버전에 대한 문서를 제공하고 있다.
|
||||
|
||||
쿠버네티스 버전에 따른 문서 제공 여부는
|
||||
현재 해당 릴리즈를 지원하는 것과 별개이다.
|
||||
[지원 기간](/releases/patch-releases/#support-period)에서
|
||||
공식적으로 지원하는 쿠버네티스 버전과 지원 기간을 알 수 있다.
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 10 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 15 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 15 KiB |
|
|
@ -77,9 +77,11 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
|
|||
* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
|
||||
* [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
|
||||
* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
|
||||
* [kube-apiserver 요청 제한 (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
|
||||
* [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
|
||||
[kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
|
||||
* [kubelet 자격증명 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
|
||||
* [kubelet 자격증명 제공자 (v1beta1)](/docs/reference/config-api/kubelet-credentialprovider.v1beta1/)
|
||||
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
|
||||
[kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
|
|
@ -87,6 +89,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
|
|||
* [클라이언트 인증 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/)
|
||||
|
||||
## kubeadm을 위한 API 설정
|
||||
|
||||
|
|
@ -96,5 +99,5 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
|
|||
## 설계 문서
|
||||
|
||||
쿠버네티스 기능에 대한 설계 문서의 아카이브.
|
||||
[쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와
|
||||
[쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
|
||||
[쿠버네티스 아키텍처](https://git.k8s.io/design-proposals-archive/architecture/architecture.md)와
|
||||
[쿠버네티스 디자인 개요](https://git.k8s.io/design-proposals-archive)부터 읽어보는 것이 좋다.
|
||||
|
|
|
|||
|
|
@ -24,3 +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 [TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함함
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음)
|
|||
|
||||
#### API 접근 확인
|
||||
|
||||
`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
|
||||
`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 `auth can-i` 하위 명령어를 제공한다.
|
||||
이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며,
|
||||
사용되는 인가 모드에 관계없이 작동한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -760,7 +760,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다.
|
||||
- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
|
||||
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
|
||||
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md)
|
||||
호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
|
||||
마운트할 수 있다.
|
||||
- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록
|
||||
|
|
@ -1087,10 +1087,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
참조한다.
|
||||
- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
|
||||
자세한 내용은
|
||||
[kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
|
||||
[kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
|
||||
- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
|
||||
자세한 사항은
|
||||
[kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
|
||||
[kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
|
||||
- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를
|
||||
활성화한다.
|
||||
- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: 애드온(Add-ons)
|
||||
id: addons
|
||||
date: 2019-12-15
|
||||
full_link: /ko/docs/concepts/cluster-administration/addons/
|
||||
short_description: >
|
||||
쿠버네티스의 기능을 확장하는 리소스.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
쿠버네티스의 기능을 확장하는 리소스.
|
||||
|
||||
<!--more-->
|
||||
[애드온 설치](/ko/docs/concepts/cluster-administration/addons/)에서는 클러스터에서 애드온을 사용하는 자세한 방법을 설명하며, 인기 있는 애드온들을 나열한다.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: 어피니티 (Affinity)
|
||||
id: affinity
|
||||
date: 2019-01-11
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
|
||||
short_description: >
|
||||
파드를 배치할 위치를 결정하기 위해 스케줄러에서 사용하는 규칙
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
|
||||
쿠버네티스에서 _어피니티_ 는 파드를 배치할 위치에 대한 힌트를 스케줄러에 제공하는 일련의 규칙이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
어피니티에는 다음의 두 가지 종류가 있다.
|
||||
|
||||
- [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)
|
||||
- [파드 간 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
|
||||
|
||||
어피니티 규칙은 쿠버네티스 {{< glossary_tooltip term_id="label" text="레이블">}} 및 {{< glossary_tooltip term_id="pod" text="파드" >}}에 명시된 {{< glossary_tooltip term_id="selector" text="셀렉터">}}를 이용하여 정의되며,
|
||||
스케줄러에서 얼마나 엄격하게 적용할지에 따라 필수 또는 선호사항으로 지정할 수 있다.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: 승인자(Approver)
|
||||
id: approver
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
쿠버네티스 코드 컨트리뷰션을 리뷰하고 승인할 수 있는 사람.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
쿠버네티스 코드 컨트리뷰션을 리뷰하고 승인할 수 있는 사람.
|
||||
|
||||
<!--more-->
|
||||
|
||||
코드 리뷰는 코드의 품질과 정확성에 초점을 맞추지만, 승인은 컨트리뷰션의 수용 여부(acceptance)를 전체적인 측면에서 바라본다. 전체적인 검토에는 앞뒤 버전과의 호환성, API 및 플래그 규칙 준수, 미묘한 성능 및 정확성 문제, 시스템의 다른 부분과의 상호작용 등이 포함된다. 승인자 자격은 코드 베이스의 일부로 범위가 한정된다. 승인자는 이전에 메인테이너라고 지칭되었다.
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: CIDR
|
||||
id: cidr
|
||||
date: 2019-11-12
|
||||
full_link:
|
||||
short_description: >
|
||||
CIDR은 IP 주소 블록을 설명하는 표기법으로 다양한 네트워킹 구성에서 많이 사용한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
CIDR (Classless Inter-Domain Routing)은 IP 주소 블록을 설명하는 표기법으로 다양한 네트워킹 구성에서 많이 사용한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스에서는 CIDR을 사용하여 시작 주소와 서브넷 마스크로 각 {{< glossary_tooltip text="노드" term_id="node" >}}에 IP 주소 범위를 할당한다.
|
||||
이를 통해 노드는 각 {{< glossary_tooltip text="파드" term_id="pod" >}}에 고유한 IP 주소를 할당할 수 있다. 원래 IPv4를 위한 개념이었지만 CIDR은 IPv6도 포함하도록 확장됐다.
|
||||
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: 클러스터 인프라스트럭처(Cluster Infrastructure)
|
||||
id: cluster-infrastructure
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: 클라우드 네이티브 컴퓨팅 재단(CNCF)
|
||||
id: cncf
|
||||
date: 2019-05-26
|
||||
full_link: https://cncf.io/
|
||||
short_description: >
|
||||
클라우드 네이티브 컴퓨팅 재단
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
클라우드 네이티브 컴퓨팅 재단(CNCF)은 지속 가능한 생태계를 구축하고
|
||||
컨테이너를 마이크로서비스 아키텍처의 일부로 오케스트레이션 하는 [프로젝트](https://www.cncf.io/projects/)
|
||||
를 중심으로 커뮤니티를 조성한다.
|
||||
|
||||
쿠버네티스는 CNCF 프로젝트이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
CNCF는 [리눅스 재단]((https://www.linuxfoundation.org/))의 산하 기구이다.
|
||||
CNCF의 목표는 어디서나 클라우드 네이티브 컴퓨팅을 활용할 수 있도록 만드는 것이다.
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: 코드 컨트리뷰터(Code Contributor)
|
||||
id: code-contributor
|
||||
date: 2018-04-12
|
||||
full_link: /ko/docs/community/devel/
|
||||
short_description: >
|
||||
쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
- user-type
|
||||
---
|
||||
쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람.
|
||||
|
||||
<!--more-->
|
||||
|
||||
그들은 하나 이상의 {{< glossary_tooltip text="Special Interest Group (SIG)" term_id="sig" >}}에 참여하는 활동적인 {{< glossary_tooltip text="커뮤니티 멤버" term_id="member" >}}이기도 하다.
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: 중단(Disruption)
|
||||
id: disruption
|
||||
date: 2019-09-10
|
||||
full_link: /ko/docs/concepts/workloads/pods/disruptions/
|
||||
short_description: >
|
||||
파드의 서비스 중단으로 이어지는 이벤트
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
중단은 하나 이상의 {{< glossary_tooltip term_id="pod" text="파드" >}}를
|
||||
중단시키게 만드는 이벤트를 의미한다.
|
||||
중단은 {{< glossary_tooltip term_id="deployment" >}}와 같이
|
||||
해당 영향을 받는 파드에 의존하는 워크로드 리소스에도 영향을
|
||||
준다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
클러스터 오퍼레이터로서, 애플리케이션에 속한 파드를 직접 파괴하는 경우
|
||||
쿠버네티스는 이를 _자발적 중단(voluntary disruption)_ 이라고 칭한다.
|
||||
노드 장애 또는 더 넓은 영역에 장애를 일으키는 정전 등으로 인해 파드가 오프라인 상태가 되면
|
||||
쿠버네티스는 이를 _비자발적 중단(involuntary disruption)_ 이라고 한다.
|
||||
|
||||
자세한 정보는 [중단](/ko/docs/concepts/workloads/pods/disruptions/)을 확인한다.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: 도커심(Dockershim)
|
||||
id: dockershim
|
||||
date: 2022-04-15
|
||||
full_link: /dockershim
|
||||
short_description: >
|
||||
쿠버네티스 1.23 이하의 버전에서 쿠버네티스 시스템 구성 요소가 도커 엔진과 통신할 수 있게 해주는 컴포넌트
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
도커심(Dockershim)은 쿠버네티스 버전 1.23 이하의 구성 요소이다.
|
||||
kubelet이 {{< glossary_tooltip text="도커 엔진" term_id="docker" >}}과 통신할 수 있게 한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거되었다. 자세한 사항은 [Dockershim FAQ](/dockershim)를 참고한다.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: 엔드포인트(Endpoints)
|
||||
id: endpoints
|
||||
date: 2020-04-23
|
||||
full_link:
|
||||
short_description: >
|
||||
엔드포인트는 서비스(Service) 셀렉터에 매치되는 파드의 IP 주소를 추적한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
엔드포인트는 서비스(Service) {{< glossary_tooltip term_id="selector" >}}에 매치되는 파드의 IP 주소를 추적한다. (API에서 해당 `kind`의 명칭은 `Endpoints`이며, 복수형이 기본임을 유의한다.)
|
||||
|
||||
<!--more-->
|
||||
엔드포인트는 셀렉터를 명시하지 않고도 {{< glossary_tooltip term_id="service" >}}에 대해 수동으로 구성할 수 있다.
|
||||
{{< glossary_tooltip text="엔드포인트슬라이스(EndpointSlice)" term_id="endpoint-slice" >}} 리소스는 엔드포인트의 대안으로, 확장성(scalability)과 확장 가능성(extensibility)을 제공한다.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: 임시 컨테이너(Ephemeral Container)
|
||||
id: ephemeral-container
|
||||
date: 2019-08-26
|
||||
full_link: /ko/docs/concepts/workloads/pods/ephemeral-containers/
|
||||
short_description: >
|
||||
파드 내에 임시적으로 실행할 수 있는 컨테이너 타입
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}} 내에 임시적으로 실행할 수 있는 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 타입.
|
||||
|
||||
<!--more-->
|
||||
|
||||
문제가 있는 실행 중 파드를 조사하고 싶다면, 파드에 임시 컨테이너를 추가하고 진단을 수행할 수 있다. 임시 컨테이너는 리소스 및 스케줄링에 대한 보장이 제공되지 않으며, 워크로드 자체를 실행하기 위해 임시 컨테이너를 사용해서는 안 된다.
|
||||
|
||||
<!-- Even though the English doc doesn't mention this, the link below is to help Korean readers understand what 임시 컨테이너 equates to in the API. -->
|
||||
더 자세한 정보는 파드 API의 [EphemeralContainer](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#EphemeralContainer)를 참고한다.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
title: 이벤트(Event)
|
||||
id: event
|
||||
date: 2022-01-16
|
||||
full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/
|
||||
short_description: >
|
||||
클러스터 어딘가에서 발생한 이벤트에 대한 보고서이다. 일반적으로 시스템의 상태 변화를 나타낸다.
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
각 이벤트는 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 어딘가에서 발생한 이벤트에 대한 보고서이다.
|
||||
일반적으로 시스템의 상태 변화를 나타낸다.
|
||||
|
||||
<!--more-->
|
||||
이벤트의 보존(retention) 시간은 제한되어 있으며, 트리거(trigger)와 메시지(message)는 시간에 따라 변화할 수 있다.
|
||||
이벤트 소비자는 일관성 있는 기본 트리거를 반영한다거나 이벤트가 지속적으로 존재한다는
|
||||
특정 이유로 이벤트의 타이밍에 의존해서는 안 된다.
|
||||
|
||||
|
||||
이벤트는 유익(imformative)해야 하고, 최선을 다한(best-effort), 보완적(supplemental) 데이터로 취급되어야 한다.
|
||||
|
||||
쿠버네티스에서, [감사(auditing)](/docs/tasks/debug/debug-cluster/audit/)는 다른 종류의 이벤트 레코드를 생성한다. (API 그룹 `audit.k8s.io`).
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: 파이널라이저(Finalizer)
|
||||
id: finalizer
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/overview/working-with-objects/finalizers/
|
||||
short_description: >
|
||||
쿠버네티스가 오브젝트를 완전히 삭제하기 이전, 삭제 표시를 위해
|
||||
특정 조건이 충족될 때까지 대기하도록 알려주기 위한 네임스페이스에 속한 키(namespaced key)이다.
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
파이널라이저는 쿠버네티스가 오브젝트를 완전히 삭제하기 이전, 삭제 표시를 위해
|
||||
특정 조건이 충족될 때까지 대기하도록 알려주기 위한 네임스페이스에 속한 키(namespaced key)이다.
|
||||
파이널라이저는 삭제 완료된 오브젝트가 소유한 리소스를 정리하기 위해
|
||||
{{<glossary_tooltip text="컨트롤러" term_id="controller">}}에게 알린다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
파이널라이저를 가진 특정한 오브젝트를 쿠버네티스가 삭제하도록 지시할 때,
|
||||
쿠버네티스 API는 `.metadata.delationTimestamp`을 덧붙여 삭제하도록 오브젝트에 표시하며,
|
||||
`202` 상태코드(HTTP "Accepted")을 리턴한다. 대상 오브젝트가 Terminating 상태를 유지하는 동안 컨트롤 플레인
|
||||
또는 다른 컴포넌트는 하나의 파이널라이저에서 정의한 작업을 수행한다.
|
||||
정의된 작업이 완료 후에, 그 컨트롤러는 대상 오브젝트로부터 연관된 파이널라이저을 삭제한다.
|
||||
`metadata.finalizers` 필드가 비어 있을 때, 쿠버네티스는
|
||||
삭제가 완료된 것으로 간주하고 오브젝트를 삭제한다.
|
||||
|
||||
파이널라이저가 리소스들의 {{<glossary_tooltip text="가비지 컬렉션" term_id="garbage-collection">}}을 제어하도록
|
||||
사용할 수 있다. 예를 들어, 하나의 파이널라이저를 컨트롤러가 대상 리소소를 삭제하기 전에
|
||||
연관된 리소스들 또는 인프라를 정리하도록 정의할 수 있다.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: 헬름 차트(Helm Chart)
|
||||
id: helm-chart
|
||||
date: 2018-04-12
|
||||
full_link: https://helm.sh/ko/docs/topics/charts/
|
||||
short_description: >
|
||||
헬름(Helm) 도구를 통해 관리할 수 있는 사전 구성된 쿠버네티스 리소스 패키지
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
헬름(Helm) 도구를 통해 관리할 수 있는 사전 구성된 쿠버네티스 리소스 패키지
|
||||
|
||||
<!--more-->
|
||||
|
||||
차트는 쿠버네티스 애플리케이션을 생성하고 공유하는 반복 가능한 방법을 제공한다.
|
||||
단일 차트는 Memcached 파드와 같이 간단한 것부터 HTTP 서버, 데이터베이스, 캐시 등이 포함된 전체 웹 앱 스택과 같은 복잡한 것까지 배포하는 데 사용할 수 있다.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Horizontal Pod Autoscaler
|
||||
id: horizontal-pod-autoscaler
|
||||
date: 2018-04-12
|
||||
full_link: /ko/docs/tasks/run-application/horizontal-pod-autoscale/
|
||||
short_description: >
|
||||
CPU 사용률 또는 사용자 정의 메트릭을 기반으로 파드의 레플리카 수를 자동으로 조절하는 API 리소스이다.
|
||||
|
||||
aka:
|
||||
- HPA
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
CPU 사용률 또는 사용자 정의 메트릭을 기반으로 {{< glossary_tooltip text="파드" term_id="pod" >}}의 레플리카 수를 자동으로 조절하는 API 리소스이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
HPA는 일반적으로 {{< glossary_tooltip text="레플리케이션 컨트롤러" term_id="replication-controller" >}}, {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}, {{< glossary_tooltip text="레플리카셋" term_id="replica-set" >}}과 함께 사용된다. 조절할 수 없는 개체(예: {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: 호스트에일리어스(HostAlias)
|
||||
id: HostAliases
|
||||
date: 2019-01-31
|
||||
full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
|
||||
short_description: >
|
||||
호스트에일리어스는 파드의 hosts 파일에 주입될 IP 주소와 호스트네임간의 매핑이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
호스트에일리어스는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 hosts 파일에 주입될 IP 주소와 호스트네임간의 매핑이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
[호스트에일리어스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core)은 명시된 경우에만 파드의 hosts 파일에 주입되는 호스트네임 및 IP 주소의 선택적 목록이다. 이는 hostNetwork 모드를 사용하고 있지 않은 파드에서만 유효하다.
|
||||
|
|
@ -16,5 +16,5 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Istio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않는다. 그것은 서비스와 네트워크 사이의 인프라스트럭쳐 레이어이다. 이는 서비스 디플로이먼트와 조합되었을 때, 일반적으로 서비스 메시라고 일컫는다. Istio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화한다.
|
||||
Istio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않는다. 그것은 서비스와 네트워크 사이의 인프라스트럭처 레이어이다. 이는 서비스 디플로이먼트와 조합되었을 때, 일반적으로 서비스 메시라고 일컫는다. Istio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: kubeadm
|
||||
id: kubeadm
|
||||
date: 2018-04-12
|
||||
full_link: /docs/admin/kubeadm/
|
||||
short_description: >
|
||||
쿠버네티스를 빠르게 설치하고 안전한(secure) 클러스터를 설정하는 도구
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
---
|
||||
쿠버네티스를 빠르게 설치하고 안전한(secure) 클러스터를 설정하는 도구
|
||||
|
||||
<!--more-->
|
||||
|
||||
kubeadm을 사용하여 컨트롤 플레인과 {{< glossary_tooltip text="워커 노드" term_id="node" >}} 구성 요소를 설치할 수 있다.
|
||||
|
||||
|
|
@ -7,7 +7,6 @@ short_description: >
|
|||
타사 공급자가 유지보수하는 소프트웨어.
|
||||
|
||||
aka:
|
||||
|
||||
tags:
|
||||
- extension
|
||||
---
|
||||
|
|
@ -17,6 +16,3 @@ tags:
|
|||
|
||||
매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고
|
||||
GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다.
|
||||
[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
|
||||
{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는
|
||||
매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: 멤버(Member)
|
||||
id: member
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
K8s 커뮤니티에서 지속적으로 활동하는 컨트리뷰터.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
K8s 커뮤니티에서 지속적으로 활동하는 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
멤버는 이슈와 풀 리퀘스트를 할당받을 수 있으며 GitHub 팀을 통해 {{< glossary_tooltip text="SIG" term_id="sig" >}}에 참여할 수 있다. 멤버의 풀 리퀘스트에 대해 병합 전 테스트(pre-submit test)가 자동으로 실행된다. 멤버는 커뮤니티에 적극적으로 기여할 것으로 기대된다.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: 파드 프라이어리티(Pod Priority)
|
||||
id: pod-priority
|
||||
date: 2019-01-31
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위
|
||||
short_description: >
|
||||
파드 프라이어리티는 다른 파드에 대한 상대적인 중요도를 나타낸다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
파드 프라이어리티는 다른 {{< glossary_tooltip text="파드" term_id="pod" >}}에 대한 상대적인 중요도를 나타낸다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
[파드 프라이어리티](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위)는 특정 파드에 다른 파드와 비교하여 높거나 낮은 스케줄링 우선 순위를 설정할 수 있도록 해 주며, 이는 프로덕션 클러스터 워크로드에 있어서 중요한 기능이다.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: 선점(Preemption)
|
||||
id: preemption
|
||||
date: 2019-01-31
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#선점
|
||||
short_description: >
|
||||
쿠버네티스에서 선점(preemption)은 노드에서 낮은 우선 순위를 가지는 파드를 축출함으로써 보류 중인 파드가 적절한 노드를 찾을 수 있도록 한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- operation
|
||||
---
|
||||
쿠버네티스에서 선점(preemption)은 노드에서 낮은 우선 순위를 가지는 {{< glossary_tooltip term_id="pod" >}}를 축출함으로써 보류 중인 파드가 적절한 {{< glossary_tooltip term_id="node" >}}를 찾을 수 있도록 한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
파드를 스케줄링 할 수 없는 경우, 스케줄러는 우선 순위가 낮은 파드를 [선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#선점)하여 보류 중인 파드를 스케줄링할 수 있게 한다.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: 프록시(Proxy)
|
||||
id: proxy
|
||||
date: 2019-09-10
|
||||
short_description: >
|
||||
클라이언트와 서버 간의 중개자 역할을 하는 애플리케이션
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
컴퓨팅에서 프록시는 원격 서비스를 위한 중개자 역할을 하는 서버이다.
|
||||
|
||||
|
||||
<!--more-->
|
||||
|
||||
클라이언트는 프록시와 통신한다. 프록시는 클라이언트에게 받은 데이터를 복사하여 실제 서버에게 보내고
|
||||
실제 서버는 이에 대한 응답을 프록시에게 보낸다. 마지막으로 프록시는 실제 서버에게 받은 응답을 클라이언트에게 전달한다.
|
||||
|
||||
|
||||
[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는
|
||||
클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service">}} 개념의
|
||||
일부를 구현한다.
|
||||
|
||||
kube-proxy를 일반 사용자 영역 프록시(plain userland proxy) 서비스로 실행할 수 있다. 운영체제가 지원한다면,
|
||||
더 적은 시스템 리소스를 사용하여 동일한 효과를 내는 하이브리드 방식으로 kube-proxy를 대신 실행할 수 있다.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: 리뷰어(Reviewer)
|
||||
id: reviewer
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
프로젝트 일부에 대한 코드를 품질과 정확성 관점에서 검토하는 사람.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
프로젝트 일부에 대한 코드를 품질과 정확성 관점에서 검토하는 사람.
|
||||
|
||||
<!--more-->
|
||||
|
||||
리뷰어는 코드베이스와 소프트웨어 엔지니어링 원칙에 대해 잘 알고 있다. 리뷰어의 상태는 코드베이스의 일부로 범위가 한정된다.
|
||||
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
title: 서비스 브로커(Service Broker)
|
||||
id: service-broker
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
서드파티에서 제공하고 유지 관리하는 일련의 매니지드 서비스에 대한 엔드포인트이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- extension
|
||||
---
|
||||
서드파티에서 제공하고 유지 관리하는 일련의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}에 대한 엔드포인트이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}는
|
||||
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)를
|
||||
구현하고 애플리케이션이 매니지드 서비스를 사용할 수 있도록 표준 인터페이스를 제공한다.
|
||||
[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
|
||||
서비스 브로커가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
|
||||
|
||||
|
|
@ -4,15 +4,15 @@ id: service-catalog
|
|||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다.
|
||||
쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이, 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록 해주던 이전의 확장 API이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- extension
|
||||
---
|
||||
쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다.
|
||||
쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이, 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록 해주던 이전의 확장 API이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
서비스 생성 또는 관리에 대한 자세한 지식 없이도 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}를 통해 외부의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}의 목록과 프로비전, 바인딩하는 방법을 제공한다.
|
||||
서비스 생성 또는 관리에 대한 자세한 지식 없이도 외부의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}의 목록과 프로비전, 바인딩하는 방법을 제공한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: SIG(special interest group)
|
||||
id: sig
|
||||
date: 2018-04-12
|
||||
full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups
|
||||
short_description: >
|
||||
대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 멤버들이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 {{< glossary_tooltip text="멤버" term_id="member" >}}들이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
SIG 멤버들은 아키텍처, API, 또는 문서화 같이 특정 영역을 발전시키는 데 공통적으로 관심을 갖고 있다.
|
||||
기본적으로 SIG [거버넌스 지침](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)을 따라야 하지만, 자체적으로 기여 정책이나 소통 채널을 가질 수 있다.
|
||||
|
||||
자세한 내용은 [kubernetes/community](https://github.com/kubernetes/community) 저장소 및 현재 존재하는 [SIG 및 WG](https://github.com/kubernetes/community/blob/master/sig-list.md) 목록을 참조한다.
|
||||
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: WG(working group)
|
||||
id: wg
|
||||
date: 2018-04-12
|
||||
full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list
|
||||
short_description: >
|
||||
위원회(committee), SIG 내, 또는 SIG 간 노력을 위한 단기적이거나, 좁은 범위를 다루거나, 혹은 서로 연관되지 않은 프로젝트의 토론 및/또는 구현을 촉진한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
|
||||
위원회(committee), {{< glossary_tooltip text="SIG" term_id="sig" >}} 내, 또는 SIG 간 노력을 위한 단기적이거나, 좁은 범위를 다루거나, 혹은 서로 연관되지 않은 프로젝트의 토론 및 구현을 촉진한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
WG은 별개의 작업을 수행하기 위해 사람들을 조직하는 한 방법이다.
|
||||
|
||||
자세한 내용은 [kubernetes/community](https://github.com/kubernetes/community) 저장소 및 현재 존재하는 [SIG 및 WG](https://github.com/kubernetes/community/blob/master/sig-list.md) 목록을 참조한다.
|
||||
|
|
@ -30,14 +30,14 @@ echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash
|
|||
|
||||
```bash
|
||||
alias k=kubectl
|
||||
complete -F __start_kubectl k
|
||||
complete -o default -F __start_kubectl k
|
||||
```
|
||||
|
||||
### ZSH
|
||||
|
||||
```bash
|
||||
source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정
|
||||
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
|
||||
echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
|
||||
```
|
||||
### --all-namespaces 에 대한 노트
|
||||
|
||||
|
|
@ -265,22 +265,22 @@ kubectl autoscale deployment foo --min=2 --max=10 # 디플로이
|
|||
## 리소스 패치
|
||||
|
||||
```bash
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트
|
||||
# 노드를 부분적으로 업데이트
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요.
|
||||
# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
|
||||
# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트.
|
||||
# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트
|
||||
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
|
||||
|
||||
# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화.
|
||||
# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# 위치 배열에 새 요소 추가
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
|
||||
# Update a deployment's replicas count by patching it's scale subresource
|
||||
# 디플로이먼트의 scale 서브리소스를 패치하여 레플리카 카운트를 업데이트.
|
||||
# 디플로이먼트의 scale 서브리소스를 패치하여 레플리카 수 업데이트
|
||||
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'
|
||||
```
|
||||
|
||||
|
|
@ -381,7 +381,10 @@ kubectl cluster-info # 마스
|
|||
kubectl cluster-info dump # 현재 클러스터 상태를 stdout으로 덤프
|
||||
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프
|
||||
|
||||
# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다.
|
||||
# 현재 노드에 존재하고 있는 테인트(taint)들을 확인
|
||||
kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect
|
||||
|
||||
# 이미 존재하고 있는 key와 effect를 갖는 테인트의 경우, 지정한 값으로 대체
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
title: 잘 알려진 레이블, 어노테이션, 테인트(Taint)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -10,10 +11,80 @@ weight: 20
|
|||
|
||||
이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## API 오브젝트에서 사용되는 레이블, 어노테이션, 테인트
|
||||
|
||||
### app.kubernetes.io/component
|
||||
|
||||
예시: `app.kubernetes.io/component: "database"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
아키텍처 내의 컴포넌트.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/created-by
|
||||
|
||||
예시: `app.kubernetes.io/created-by: "controller-manager"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
리소스를 생성한 컨트롤러/사용자.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/instance
|
||||
|
||||
예시: `app.kubernetes.io/instance: "mysql-abcxzy"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
애플리케이션 인스턴스를 식별하기 위한 고유한 이름.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/managed-by
|
||||
|
||||
예시: `app.kubernetes.io/managed-by: "helm"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
애플리케이션의 작업을 관리하기 위해 사용되는 도구.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/name
|
||||
|
||||
예시: `app.kubernetes.io/name: "mysql"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
애플리케이션의 이름.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/part-of
|
||||
|
||||
예시: `app.kubernetes.io/part-of: "wordpress"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
해당 애플리케이션이 속한 상위 레벨의 애플리케이션 이름.
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
### app.kubernetes.io/version
|
||||
|
||||
예시: `app.kubernetes.io/version: "5.7.21"`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
애플리케이션의 현재 버전(시맨틱 버전, 리비전 해시, 기타 등등).
|
||||
|
||||
[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다.
|
||||
|
||||
## kubernetes.io/arch
|
||||
|
||||
예시: `kubernetes.io/arch=amd64`
|
||||
|
|
@ -72,15 +143,69 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k
|
|||
|
||||
어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다.
|
||||
|
||||
### kubernetes.io/description {#description}
|
||||
|
||||
예시: `kubernetes.io/description: "Description of K8s object."`
|
||||
|
||||
적용 대상: 모든 오브젝트
|
||||
|
||||
이 어노테이션은 주어진 오브젝트의 특정 상태를 표현하는데 사용한다.
|
||||
|
||||
### kubernetes.io/enforce-mountable-secrets {#enforce-mountable-secrets}
|
||||
|
||||
예시: `kubernetes.io/enforce-mountable-secrets: "true"`
|
||||
|
||||
적용 대상: 서비스어카운트(ServiceAccount)
|
||||
|
||||
이 어노테이션의 값은 **true**로 설정되어야만 작동한다. 이 어노테이션은, 해당 서비스어카운트로 동작중인 파드가 그 서비스어카운트의 `secrets` 항목에 명시된 Secret API 오브젝트만을 참조한다는 뜻이다.
|
||||
|
||||
## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
|
||||
|
||||
예시: `controller.kubernetes.io/pod-deletion-cost=10`
|
||||
|
||||
적용 대상: Pod
|
||||
적용 대상: 파드
|
||||
|
||||
이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을
|
||||
설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다.
|
||||
|
||||
### kubernetes.io/ingress-bandwidth
|
||||
|
||||
{{< note >}}
|
||||
인그레스 트래픽 조절 어노테이션은 실험적인 기능이다.
|
||||
만약 트래픽 조절 기능을 활성화시키고 싶다면, CNI 설정 파일(기본적으로 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 추가해야 하며,
|
||||
실행파일이 CNI의 실행파일 경로(기본적으로 `/opt/cni/bin`) 아래에 포함되어있는지도 확인하자.
|
||||
{{< /note >}}
|
||||
|
||||
Example: `kubernetes.io/ingress-bandwidth: 10M`
|
||||
|
||||
적용 대상: 파드
|
||||
|
||||
파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다.
|
||||
인그레스 트래픽(파드로 향하는)은 효과적으로 데이터를 처리하기 위해 대기 중인 패킷을 큐로 관리한다.
|
||||
파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고
|
||||
`kubernetes.io/ingress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 인그레스 속도를 명시할 때 사용되는 단위는
|
||||
초당 비트([수량](/docs/reference/kubernetes-api/common-definitions/quantity/))이다.
|
||||
예를 들어, `10M`은 초당 10 메가비트를 의미한다.
|
||||
|
||||
### kubernetes.io/egress-bandwidth
|
||||
|
||||
{{< note >}}
|
||||
이그레스 트래픽 조절 어노테이션은 실험적인 기능이다.
|
||||
만약 트래픽 조절 기능을 활성화시키고 싶다면, CNI 설정 파일(기본적으로 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 추가해야 하며,
|
||||
실행파일이 CNI의 실행파일 경로(기본적으로 `/opt/cni/bin`) 아래에 포함되어있는지도 확인하자.
|
||||
{{< /note >}}
|
||||
|
||||
예시: `kubernetes.io/egress-bandwidth: 10M`
|
||||
|
||||
적용 대상: 파드
|
||||
|
||||
이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며,
|
||||
파드에 거는 제한은 다른 파드의 대역폭에 영향을 주지 않는다.
|
||||
파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고
|
||||
`kubernetes.io/egress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 이그레스 속도를 명시할 때 사용되는 단위는
|
||||
초당 비트([수량](/docs/reference/kubernetes-api/common-definitions/quantity/))이다.
|
||||
예를 들어, `10M`은 초당 10 메가비트를 의미한다.
|
||||
|
||||
## beta.kubernetes.io/instance-type (사용 중단됨)
|
||||
|
||||
{{< note >}} v1.17부터, [`node.kubernetes.io/instance-type`](#nodekubernetesioinstance-type)으로 대체되었다. {{< /note >}}
|
||||
|
|
@ -163,13 +288,23 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클
|
|||
|
||||
예시: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath`
|
||||
|
||||
적용 대상: PersistentVolumeClaim
|
||||
적용 대상: 퍼시스턴트볼륨클레임(PersistentVolumeClaim)
|
||||
|
||||
이 어노테이션은 사용 중단되었다.
|
||||
|
||||
### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options}
|
||||
|
||||
예시 : `volume.beta.kubernetes.io/mount-options: "ro,soft"`
|
||||
|
||||
적용 대상: 퍼시스턴트볼륨
|
||||
|
||||
쿠버네티스 관리자는, 노드에 퍼시스턴트볼륨이 마운트될 경우 추가적인 [마운트 옵션](/ko/docs/concepts/storage/persistent-volumes/#mount-options)을 명세할 수 있다.
|
||||
|
||||
이 어노테이션은 사용 중단되었다.
|
||||
|
||||
## volume.kubernetes.io/storage-provisioner
|
||||
|
||||
적용 대상: PersistentVolumeClaim
|
||||
적용 대상: 퍼시스턴트볼륨클레임
|
||||
|
||||
이 어노테이션은 동적 프로비저닝이 요구되는 PVC에 추가될 예정이다.
|
||||
|
||||
|
|
@ -199,6 +334,24 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
|
|||
|
||||
쿠버네티스가 여러 서비스를 구분하기 위해 이 레이블을 사용한다. 현재는 `ELB`(Elastic Load Balancer) 를 위해서만 사용되고 있다.
|
||||
|
||||
### kubernetes.io/service-account.name
|
||||
|
||||
예시: `kubernetes.io/service-account.name: "sa-name"`
|
||||
|
||||
Used on: 시크릿(Secret)
|
||||
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
서비스어카운트의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다.
|
||||
|
||||
### kubernetes.io/service-account.uid
|
||||
|
||||
예시: `kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da`
|
||||
|
||||
적용 대상: 시크릿
|
||||
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
서비스어카운트의 {{< glossary_tooltip term_id="uid" text="고유 ID">}}를 기록한다.
|
||||
|
||||
## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
|
||||
|
||||
예시: `endpointslice.kubernetes.io/managed-by="controller"`
|
||||
|
|
@ -257,7 +410,7 @@ v1.18부터, `spec.ingressClassName`으로 대체되었다.
|
|||
적용 대상: 스토리지클래스(StorageClass)
|
||||
|
||||
하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우,
|
||||
클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 리소스는 해당 기본 클래스로 할당될 것이다.
|
||||
클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임 리소스는 해당 기본 클래스로 할당될 것이다.
|
||||
|
||||
## alpha.kubernetes.io/provided-node-ip
|
||||
|
||||
|
|
@ -354,6 +507,21 @@ kubelet은 노드의 `imagefs.available`, `imagefs.inodesFree`, `nodefs.availabl
|
|||
|
||||
kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠버네티스가 사용 중인 PID를 확인하여, `pid.available` 지표라고 불리는 '사용 가능한 PID 수'를 가져온다. 그 뒤, 관측한 지표를 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다.
|
||||
|
||||
### node.kubernetes.io/out-of-service
|
||||
|
||||
예시: `node.kubernetes.io/out-of-service:NoExecute`
|
||||
|
||||
사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 `kube-controller-manager`에 활성화되어 있으며
|
||||
노드가 이 테인트로 인해 서비스 중이 아니라고 표시되어있을 경우, 노드에서 실행되던 매칭되는 톨러레이션이 없는 파드들은 강제로 삭제됨과 동시에 볼륨이 분리된다. 이는 서비스 중이 아닌 노드의 파드들이 다른 노드에서 빠르게 복구될 수 있도록 해준다.
|
||||
|
||||
{{< caution >}}
|
||||
이 테인트를 언제 어떻게 사용할지에 대한 자세한 사항은
|
||||
[논 그레이스풀 노드 셧다운](/ko/docs/concepts/architecture/nodes/#non-graceful-node-shutdown)
|
||||
를 참조한다.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
## node.cloudprovider.kubernetes.io/uninitialized
|
||||
|
||||
예시: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule`
|
||||
|
|
@ -465,3 +633,94 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다.
|
||||
튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며,
|
||||
이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다.
|
||||
|
||||
### snapshot.storage.kubernetes.io/allowVolumeModeChange
|
||||
|
||||
예시: `snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"`
|
||||
|
||||
적용 대상: VolumeSnapshotContent
|
||||
|
||||
값은 `true` 혹은 `false`만을 받는다.
|
||||
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}이
|
||||
볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우,
|
||||
사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다.
|
||||
|
||||
자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode)
|
||||
와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
|
||||
|
||||
## Audit을 위한 어노테이션들
|
||||
|
||||
<!-- sorted by annotation -->
|
||||
- [`authorization.k8s.io/decision`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision)
|
||||
- [`authorization.k8s.io/reason`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason)
|
||||
- [`insecure-sha1.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#insecure-sha1-invalid-cert-kubernetes-io-hostname)
|
||||
- [`missing-san.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#missing-san-invalid-cert-kubernetes-io-hostname)
|
||||
- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
|
||||
자세한 사항은 [Audit 어노테이션](/docs/reference/labels-annotations-taints/audit-annotations/) 페이지를 참고한다.
|
||||
|
||||
## kubeadm
|
||||
|
||||
### kubeadm.alpha.kubernetes.io/cri-socket
|
||||
|
||||
예시: `kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/container.sock`
|
||||
|
||||
적용 대상: 노드
|
||||
|
||||
kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션.
|
||||
kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에,
|
||||
어노테이션은 "alpha" 상태로 남아있다.
|
||||
|
||||
### kubeadm.kubernetes.io/etcd.advertise-client-urls
|
||||
|
||||
예시: `kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.17.0.18:2379`
|
||||
|
||||
적용 대상: 파드
|
||||
|
||||
etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위해, 로컬에서 관리되는 etcd 파드에 배치되는 어노테이션.
|
||||
주로 etcd 클러스터의 헬스 체크에 사용한다.
|
||||
|
||||
### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint
|
||||
|
||||
예시: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443`
|
||||
|
||||
적용 대상: 파드
|
||||
|
||||
외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해,
|
||||
로컬에서 관리되는 kube-apiserver 파드에 배치되는 어노테이션.
|
||||
|
||||
### kubeadm.kubernetes.io/component-config.hash
|
||||
|
||||
예시: `kubeadm.kubernetes.io/component-config.hash: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae`
|
||||
|
||||
적용 대상: 컨피그맵(ConfigMap)
|
||||
|
||||
컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션.
|
||||
사용자가 특정 컴포넌트에 대해서 kubeadm 기본값과 다른 설정값을 적용했는지 판단하기 위한 해시(SHA-256)를 가지고 있다.
|
||||
|
||||
### node-role.kubernetes.io/control-plane
|
||||
|
||||
적용 대상: 노드
|
||||
|
||||
kubeadm이 관리하는 컨트롤 플레인 노드에 적용되는 레이블.
|
||||
|
||||
### node-role.kubernetes.io/control-plane
|
||||
|
||||
예시: `node-role.kubernetes.io/control-plane:NoSchedule`
|
||||
|
||||
적용 대상: 노드
|
||||
|
||||
중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트.
|
||||
|
||||
### node-role.kubernetes.io/master
|
||||
|
||||
예시: `node-role.kubernetes.io/master:NoSchedule`
|
||||
|
||||
적용 대상: 노드
|
||||
|
||||
중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트.
|
||||
|
||||
{{< note >}} 버전 v1.20 부터, 이 테인트는 `node-role.kubernetes.io/control-plane`의 등장으로 더 이상 사용되지 않으며,
|
||||
버전 v1.25에서 삭제될 예정이다.{{< /note >}}
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
|
|||
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
|
||||
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/design-proposals-archive/release/versioning.md)에는
|
||||
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||
|
|
@ -83,8 +83,8 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
|||
|
||||
## API 그룹
|
||||
|
||||
[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은
|
||||
쿠버네티스 API를 더 쉽게 확장하게 해준다.
|
||||
[API 그룹](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md)은
|
||||
쿠버네티스 API를 더 쉽게 확장할 수 있도록 해 준다.
|
||||
API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에
|
||||
명시된다.
|
||||
|
||||
|
|
@ -123,5 +123,5 @@ API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기
|
||||
- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에
|
||||
- [애그리게이터(aggregator)](https://git.k8s.io/design-proposals-archive/api-machinery/aggregated-api-servers.md)에
|
||||
대한 디자인 문서 읽기
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue