diff --git a/content/ko/_index.html b/content/ko/_index.html index 0925f2ef7e340..ddfa38659b23e 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -43,12 +43,12 @@
쿠버네티스는
-CNCF의 행동 강령을 따르고 있습니다.
-커밋 214585e
+CNCF의 행동 강령을 따르고 있습니다.
+커밋 71b12a2
에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다.
만약 최신 버전이 아닌 경우에는
이슈를 제기해 주세요.
diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md
index 804c5632fde23..9d191a81bbc29 100644
--- a/content/ko/community/static/cncf-code-of-conduct.md
+++ b/content/ko/community/static/cncf-code-of-conduct.md
@@ -1,28 +1,42 @@
-## 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)에 이메일
-
-![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
-
-
-### 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과 같은
- # 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.
- #####
-```
-
-다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
-
-![List Services](/images/docs/service-catalog-list.svg)
-
-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
- #####
- # 이곳에 서비스 브로커가 사용할 수 있는
- # 파라미터를 추가할 수 있다.
- #####
-```
-
-다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
-
-![Provision a Service](/images/docs/service-catalog-provision.svg)
-
-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, 서비스 어카운트 파라미터 등의
- # 추가 정보를 여기에 추가할 수 있다.
- #####
-```
-
-다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
-
-![Bind to a managed service](/images/docs/service-catalog-bind.svg)
-
-1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
-1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
-1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
-
-### 연결 자격 증명 매핑
-
-바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
-이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
-
-
-
-![Map connection credentials](/images/docs/service-catalog-map.svg)
-
-#### 파드 구성 파일
-
-이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
-
-다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `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) 프로젝트 탐색
diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md
index 0281daaae0f21..8c2ab31c68e6b 100644
--- a/content/ko/docs/concepts/overview/kubernetes-api.md
+++ b/content/ko/docs/concepts/overview/kubernetes-api.md
@@ -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(인터페이스 정의 언어) 파일을 참고한다.
diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md
index 69afaa0069890..b2af3e1f1af4d 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/names.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/names.md
@@ -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) 디자인 문서 읽기.
diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md
index 8a8270be8c500..a502c98c08679 100644
--- a/content/ko/docs/concepts/policy/limit-range.md
+++ b/content/ko/docs/concepts/policy/limit-range.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)를 참조한다.
제한의 사용에 대한 예시는 다음을 참조한다.
diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md
index 40fe11445328f..cdcd0d36cbe62 100644
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.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)을 참고한다.
diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
index 51ecff20b494c..71d053708b44f 100644
--- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -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/)를 어떻게 사용하는지 알아본다.
+
+
diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
index 0feb96eb9a5ed..dbca83de2daed 100644
--- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
+++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
@@ -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) 향상 제안을 확인한다.
+
diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
index 8c5f19b8ffe30..6ed353565974a 100644
--- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -1,72 +1,102 @@
---
-
-
-
-
-title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
+# reviewers:
+# - bsalamat
+# - k82cn
+# - ahg-g
+title: 리소스 빈 패킹(bin packing)
content_type: concept
weight: 80
---
-{{< 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) 전략이 있다.
-## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
-
-쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
-용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다.
-이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
-대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
-`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은
-`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다.
-이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다.
-`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로
-최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다.
+## MostAllocated 전략을 사용하여 빈 패킹 활성화하기
+`MostAllocated` 전략은 리소스 사용량을 기반으로 할당량이 많은 노드를 높게 평가하여 노드에 점수를 매긴다.
+각 리소스 유형별로 가중치를 설정하여 노드 점수에 미치는 영향을 조정할 수 있다.
+
+`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/)에 대해 더 읽어본다.
+
diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
index f6321e4aa7d83..423be4f69f08c 100644
--- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -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/) 고려한다.
테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지
않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은
diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md
index ad30adf3c67c2..f75e4c418592b 100644
--- a/content/ko/docs/concepts/security/controlling-access.md
+++ b/content/ko/docs/concepts/security/controlling-access.md
@@ -1,9 +1,10 @@
---
-
-
-
+# reviewers:
+# - erictune
+# - lavalamp
title: 쿠버네티스 API 접근 제어하기
content_type: concept
+weight: 50
---
@@ -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)
+ 을 사용하는 방법.
diff --git a/content/ko/docs/concepts/security/windows-security.md b/content/ko/docs/concepts/security/windows-security.md
new file mode 100644
index 0000000000000..ba984aade0323
--- /dev/null
+++ b/content/ko/docs/concepts/security/windows-security.md
@@ -0,0 +1,55 @@
+---
+# reviewers:
+# - jayunit100
+# - jsturtevant
+# - marosset
+# - perithompson
+title: 윈도우 노드에서의 보안
+content_type: concept
+weight: 40
+---
+
+
+
+이 페이지에서는 윈도우 운영 체제에서의 보안 고려 사항 및 추천 사례에 대해 기술한다.
+
+
+
+## 노드의 시크릿 데이터 보호
+
+윈도우에서, 시크릿에 있던 데이터는 노드의 로컬 스토리지에
+평문으로 기록된다(리눅스는 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)를 사용할 수 있다.
diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md
index b80c3a40f69c6..2ebb1a0b4a94e 100644
--- a/content/ko/docs/concepts/services-networking/_index.md
+++ b/content/ko/docs/concepts/services-networking/_index.md
@@ -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에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index 9b4521e2b7746..59ed5efc577c9 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -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" %}}
diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md
index 1e8c9c2a03268..276f2b50592a6 100644
--- a/content/ko/docs/concepts/services-networking/dual-stack.md
+++ b/content/ko/docs/concepts/services-networking/dual-stack.md
@@ -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 주소를 동시에 할당할 수 있다.
@@ -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=
로드 밸런서 .->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([클라이언트])-. 인그레스-매니지드
로드 밸런서 .->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([클라이언트])-. 인그레스-매니지드
로드 밸런서 .->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)에 기반한 요청을
diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md
index f72d1f0cff54c..83887b51e2ca4 100644
--- a/content/ko/docs/concepts/services-networking/network-policies.md
+++ b/content/ko/docs/concepts/services-networking/network-policies.md
@@ -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와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md
index 7696657c65c4f..c0c9e42d0d613 100644
--- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md
+++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md
@@ -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/)에 대해서 읽기
diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md
index 858c5ab09a3aa..27ab53d3d98e4 100644
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@@ -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 >}}
diff --git a/content/ko/docs/concepts/services-networking/windows-networking.md b/content/ko/docs/concepts/services-networking/windows-networking.md
new file mode 100644
index 0000000000000..400e9c51c1362
--- /dev/null
+++ b/content/ko/docs/concepts/services-networking/windows-networking.md
@@ -0,0 +1,164 @@
+---
+# reviewers:
+# - aravindhp
+# - jayunit100
+# - jsturtevant
+# - marosset
+title: 윈도우에서의 네트워킹
+content_type: concept
+weight: 75
+---
+
+
+
+쿠버네티스는 리눅스 및 윈도우 노드를 지원한다.
+단일 클러스터 내에 두 종류의 노드를 혼합할 수 있다.
+이 페이지에서는 윈도우 운영 체제에서의 네트워킹에 대한 개요를 제공한다.
+
+
+## 윈도우에서의 컨테이너 네트워킹 {#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/) 터널링을 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다.
패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다.
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