whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into zacharysarah-merged-master-dev-1.18

Browse Source
This commit is contained in:
zacharysarah
2020-03-03 12:07:32 -08:00
parent 78193337e4 c04ffcdce8
commit 4582f017e2
115 changed files with 3895 additions and 613 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/_index.md
+2 -2
View File
@@ -26,12 +26,12 @@ weight: 40
## 쿠버네티스 오브젝트
쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 문서를 참조한다.
쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다.
기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다.
* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
* [서비스](/docs/concepts/services-networking/service/)
* [서비스](/ko/docs/concepts/services-networking/service/)
* [볼륨](/docs/concepts/storage/volumes/)
* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
content/ko/docs/concepts/architecture/controller.md
+1 -1
View File
@@ -26,7 +26,7 @@ weight: 30
## 컨트롤러 패턴
컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)
이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
상태에 가깝게 만드는 역할을 한다.
content/ko/docs/concepts/architecture/nodes.md
+7 -1
View File
@@ -103,7 +103,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
## 관리
[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리,
[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/ko/docs/concepts/services-networking/service/)와 달리,
노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해
외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다.
그래서 쿠버네티스가 노드를 생성할 때,
@@ -272,6 +272,12 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다.
{{< /note >}}
{{< caution >}}
`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
{{< /caution >}}
### 노드 용량
노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다.
content/ko/docs/concepts/cluster-administration/controller-metrics.md
-48
View File
@@ -1,48 +0,0 @@
---
title: 컨트롤러 관리자 메트릭
content_template: templates/concept
weight: 100
---
{{% capture overview %}}
컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한
중요한 통찰을 제공한다.
{{% /capture %}}
{{% capture body %}}
## 컨트롤러 관리자 메트릭은 무엇인가
컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다.
메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과
etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를
측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다.
쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다.
이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다.
예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다:
```
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
## 구성
클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서
이용 가능하다.
메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다.
운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해,
프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다.
{{% /capture %}}
content/ko/docs/concepts/cluster-administration/proxies.md
+1 -1
View File
@@ -33,7 +33,7 @@ weight: 90
- 노드, 파드, 서비스에 도달하는데 사용할 수 있다.
- 서비스에 도달할 때에는 로드 밸런싱을 수행한다.
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips):
- 각 노드에서 실행한다.
- UDP, TCP, SCTP를 이용하여 프락시 한다.
content/ko/docs/concepts/configuration/overview.md
+5 -5
View File
@@ -37,7 +37,7 @@ weight: 10
## 서비스
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다.
```shell
FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
@@ -51,14 +51,14 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다.
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-
services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-
서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
## 레이블 사용하기
content/ko/docs/concepts/containers/runtime-class.md
+2 -2
View File
@@ -56,7 +56,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
{{< note >}}
런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다.
이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다.
{{< /note >}}
해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
@@ -162,7 +162,7 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
노드의 합집합을 취한다.
노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다.
[노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다.
[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/
content/ko/docs/concepts/extend-kubernetes/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: 쿠버네티스 확장하기
weight: 110
---
content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: 쿠버네티스 API 확장하기
weight: 20
---
content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+38
View File
@@ -0,0 +1,38 @@
---
title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
{{% /capture %}}
{{% capture body %}}
## 개요
애그리게이션 레이어는 부가적인 쿠버네티스-스타일 API를 클러스터에 설치할 수 있게 해준다. 이는 [서비스-카탈로그](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)와 같이 사전에 구축되어 있는 서드 파티 솔루션일 수 있고, [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)로 시작해볼 수 있는 것과 같은 사용자 정의 API일 수도 있다.
애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다.
대개, APIService는 클러스터 내에서 구동 중인 파드(pod) 내 *extension-apiserver* 로 구현된다. 이 extension-apiserver는 일반적으로 추가된 리소스에 대한 적극적인 관리가 필요한 경우 하나 이상의 컨트롤러와 짝지어진다. 결과적으로, apiserver-builder는 실제로 그 둘 모두에 대한 스켈레톤을 제공한다. 또 다른 예로, 서비스-카탈로그가 설치된 경우에는, 제공하는 서비스에 대한 extension-apiserver와 컨트롤러를 모두 제공한다.
Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다.
특히, kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
사용자의 환경에서 달성할 수 없는 경우에는, 이를 어떻게 바꿀 수 있을지 고려해야 한다. 지금은,
`EnableAggregatedDiscoveryTimeout=false` 기능 게이트를 설정해서 타임아웃 제한을
비활성화 할 수 있다. 이 기능은 미래의 릴리스에서는 삭제될 예정이다.
{{% /capture %}}
{{% capture whatsnext %}}
* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+10 -9
View File
@@ -12,7 +12,7 @@ card:
{{% /capture %}}
{{% capture body %}}
## 쿠버네티스 오브젝트 이해하기
## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}
*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.
@@ -41,8 +41,9 @@ card:
{{< codenew file="application/deployment.yaml" >}}
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는
`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
```shell
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
@@ -50,8 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
그 출력 내용은 다음과 유사하다.
```shell
```
deployment.apps/nginx-deployment created
```
@@ -65,14 +65,15 @@ deployment.apps/nginx-deployment created
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, `파드`에 대한 `spec` 포맷은
[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은
[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
예를 들어, 파드에 대한 `spec` 포맷은
[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
{{% /capture %}}
{{% capture whatsnext %}}
* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/labels.md
+3 -3
View File
@@ -70,7 +70,7 @@ spec:
image: nginx:1.7.9
ports:
- containerPort: 80
```
## 레이블 셀렉터
@@ -209,7 +209,7 @@ selector:
#### 세트-기반 요건을 지원하는 리소스
[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
```yaml
selector:
@@ -225,6 +225,6 @@ selector:
#### 노드 셋 선택
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.
자세한 내용은 [노드 선택](/ko/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다.
{{% /capture %}}
content/ko/docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -123,7 +123,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m
이제 클러스터의 모든 노드에서 `<CLUSTER-IP>:<PORT>` 로 nginx 서비스를
curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다.
[서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)에 대해 더 읽어본다.
## 서비스에 접근하기
content/ko/docs/concepts/services-networking/dns-pod-service.md
+15 -13
View File
@@ -38,22 +38,24 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
## 서비스
### A 레코드
### A/AAAA 레코드
"노멀"(헤드리스가 아닌) 서비스는
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다.
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
IP로 해석된다.
"헤드리스"(클러스터 IP가 없는) 서비스 또한
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
`my-svc.my-namespace.svc.cluster-domain.example`
형식의 이름을 가진 DNS A 레코드가 할당된다.
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
통해 선택할 수 있다.
### SRV 레코드
SRV 레코드는 노멀 서비스 또는
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
@@ -128,22 +130,22 @@ spec:
```
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다.
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예를 들어 호스트네임이 "`busybox-1`"이고,
서브도메인이 "`default-subdomain`"이고,
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다.
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다.
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.
{{< note >}}
A 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
A 레코드만 생성할 수 있다.
A 또는 AAAA 레코드만 생성할 수 있다.
(`default-subdomain.my-namespace.svc.cluster-domain.example`)
또한 레코드를 가지기 위해서는 파드가 준비되어야 한다.
그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
content/ko/docs/concepts/services-networking/dual-stack.md
+2 -3
View File
@@ -27,7 +27,6 @@ weight: 70
* 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
* IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
* Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6)
* IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)
## 필수 구성 요소
@@ -36,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
* 쿠버네티스 1.16 또는 이후 버전
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* Kubenet 네트워크 플러그인
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
* IPVS 모드에서 구동 중인 Kube-Proxy
## IPv4/IPv6 이중 스택 활성화
@@ -52,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
* `--feature-gates="IPv6DualStack=true"`
* kube-proxy:
* `--proxy-mode=ipvs`
* `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
* `--feature-gates="IPv6DualStack=true"`
{{< caution >}}
content/ko/docs/concepts/services-networking/ingress.md
+13 -21
View File
@@ -15,24 +15,15 @@ weight: 40
이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.
노드(Node)
: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster)
: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router)
: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network)
: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스(Service)
: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
## 인그레스란?
인그레스는 클러스터 외부에서 클러스터 내부
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
@@ -47,8 +38,8 @@ weight: 40
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
## 전제 조건들
@@ -107,7 +98,7 @@ spec:
* 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가
모두 수신 요청의 내용과 일치해야 한다.
* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이
* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
@@ -220,7 +211,7 @@ Events:
{{< note >}}
사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
에 따라 default-http-backend
[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
{{< /note >}}
### 이름 기반의 가상 호스팅
@@ -466,12 +457,13 @@ Events:
사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다.
* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용.
* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용.
* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용.
* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용.
{{% /capture %}}
{{% capture whatsnext %}}
* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}
content/ko/docs/concepts/services-networking/network-policies.md
+26 -71
View File
@@ -7,16 +7,16 @@ weight: 50
{{< toc >}}
{{% capture overview %}}
네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
{{% /capture %}}
{{% capture body %}}
## 전제 조건
네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다.
네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다.
## 격리 및 격리되지 않은 파드
@@ -26,11 +26,11 @@ weight: 50
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
## `NetworkPolicy` 리소스
## NetworkPolicy 리소스 {#networkpolicy-resource}
리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
`NetworkPolicy` 의 예시는 다음과 같다.
NetworkPolicy 의 예시는 다음과 같다.
```yaml
apiVersion: networking.k8s.io/v1
@@ -69,23 +69,25 @@ spec:
port: 5978
```
*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.*
{{< note >}}
선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
{{< /note >}}
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는
__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는
`apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는
[컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.
__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.
@@ -103,7 +105,7 @@ __egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포
`ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.
__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
__namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.
@@ -164,16 +166,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
```
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
@@ -181,33 +174,13 @@ spec:
만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
ingress:
- {}
policyTypes:
- Ingress
```
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
### 기본적으로 모든 이그레스 트래픽 거부
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Egress
```
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
기본 인그레스 격리 정책을 변경하지 않는다.
@@ -216,34 +189,13 @@ spec:
만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
egress:
- {}
policyTypes:
- Egress
```
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
```
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
@@ -251,9 +203,12 @@ spec:
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다.
기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다.
{{< note >}}
SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
{{< /note >}}
{{% /capture %}}
content/ko/docs/concepts/services-networking/service-topology.md
+92 -17
View File
@@ -43,23 +43,6 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
연결된 노드로 트래픽을 유지하는 것이 있다.
## 전제 조건
서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이
필요하다.
* 쿠버네티스 1.17 또는 이후 버전
* Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중
* [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화
## 서비스 토폴로지 활성화하기
서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의
기능 게이트에서 `ServiceTopology` 를 활성화 한다.
```
--feature-gates="ServiceTopology=true"
```
## 서비스 토폴로지 사용하기
@@ -114,6 +97,98 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수
한다.
## 예시들
다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다.
### 노드 로컬 엔드포인트만
노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
```
### 노드 로컬 엔드포인트 선호
노드 로컬 엔드포인트를 선호하지만, 노드 로컬 엔드포인트가 없는 경우 클러스터 전체 엔드포인트로 폴백 하는 서비스이다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
- "*"
```
### 영역 또는 지리적 엔드포인트만
영역보다는 지리적 엔드포인트를 선호하는 서비스이다. 만약 엔드포인트가 없다면, 트래픽은 드롭된다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "topology.kubernetes.io/zone"
- "topology.kubernetes.io/region"
```
### 노드 로컬, 영역 및 지역 엔드포인트 선호
노드 로컬, 영역 및 지역 엔드포인트를 선호하지만, 클러스터 전체 엔드포인트로 폴백하는 서비스이다.
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
topologyKeys:
- "kubernetes.io/hostname"
- "topology.kubernetes.io/zone"
- "topology.kubernetes.io/region"
- "*"
```
{{% /capture %}}
{{% capture whatsnext %}}
content/ko/docs/concepts/services-networking/service.md
+2 -2
View File
@@ -847,7 +847,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다.
트래픽을 균일하게 하려면, DaemonSet을 사용하거나,
[파드 안티어피니티(pod anti-affinity)](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
[파드 안티어피니티(pod anti-affinity)](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
를 지정하여 동일한 노드에 위치하지 않도록 한다.
[내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를
@@ -936,7 +936,7 @@ spec:
{{< note >}}
ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
[헤드리스(headless) 서비스](#headless-services) 사용을 고려한다.
[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다.
{{< /note >}}
`my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는
content/ko/docs/concepts/storage/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "스토리지"
weight: 70
---
content/ko/docs/concepts/storage/volumes.md
+1444
View File
File diff suppressed because it is too large Load Diff
content/ko/docs/concepts/workloads/controllers/daemonset.md
+5 -5
View File
@@ -13,8 +13,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
데몬셋의 일부 대표적인 용도는 다음과 같다.
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행.
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
@@ -88,9 +88,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 오직 일부 노드에서만 파드 실행
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와
[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와
일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다.
데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
## 데몬 파드가 스케줄 되는 방법
@@ -161,7 +161,7 @@ nodeAffinity:
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고,
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고,
그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
검색한다.
- **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
content/ko/docs/concepts/workloads/controllers/replicaset.md
+2 -2
View File
@@ -22,7 +22,7 @@ weight: 10
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
사용한다.
레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
@@ -250,7 +250,7 @@ matchLabels:
### 레플리카셋과 해당 파드 삭제
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
설정해야 한다.
content/ko/docs/concepts/workloads/controllers/statefulset.md
+3 -3
View File
@@ -34,7 +34,7 @@ weight: 40
* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
* [롤링 업데이트](#롤링-업데이트)와 기본
[파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
@@ -121,7 +121,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은
`web-0,web-1,web-2` 이다.
스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다.
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다.
이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며,
여기서 "cluster.local"은 클러스터 도메인이다.
각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고
@@ -130,7 +130,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
[제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
파드의 네트워크 신원을 책임지는
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다.
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다.
여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고,
그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+1 -1
View File
@@ -9,7 +9,7 @@ weight: 65
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
[잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
-8
View File
@@ -67,8 +67,6 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수
모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
* `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
성공적으로 시작 완료되었음.
* `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서
지금 당장은 파드를 스케줄할 수 없음.
* `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임.
@@ -256,12 +254,6 @@ status:
파드 준비성 평가에 대한 변경을 촉진하기 위해서,
이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다.
K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 위해서는
[특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를
참으로 설정함으로써 명시적으로 활성화해야 한다.
K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다.
## 재시작 정책
PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다.