First Korean L10n Work For Relase 1.17 (#18226)
* Modified link between Korean documents. (#18072) * Translate services-networking/connect-applications-service.md in Korean. (#18087) * Translate services-networking/service-topology.md in Korean. (#18096) * Update to outdated files in the dev-1.17-ko.1 (#18070) Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
f21f4b2257
commit
d60ca0bea2
@@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
|
||||
볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
|
||||
{{< /note >}}
|
||||
|
||||
CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
|
||||
CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
|
||||
|
||||
이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
|
||||
|
||||
|
||||
@@ -78,19 +78,10 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
|
||||
노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면
|
||||
노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
|
||||
|
||||
1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
|
||||
[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
|
||||
마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다.
|
||||
대신 노드의 taint와 toleration을 살펴본다.
|
||||
|
||||
현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다.
|
||||
아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의
|
||||
taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는
|
||||
시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
|
||||
{{< /caution >}}
|
||||
노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
|
||||
[테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
|
||||
스케줄러가 파드를 노드에 할당할 때, 스케줄러는 파드가 극복(tolerate)하는 테인트가
|
||||
아닌 한, 노드 계정의 테인트를 고려 한다.
|
||||
|
||||
### 용량과 할당가능 {#capacity}
|
||||
|
||||
@@ -169,18 +160,28 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는
|
||||
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
|
||||
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
|
||||
쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가
|
||||
된다. node lease 기능은 1.14 부터 기본값으로 활성화 되었으며, 베타 기능이다
|
||||
(기능 게이트 `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해
|
||||
갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고
|
||||
NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다.
|
||||
NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만
|
||||
(기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.)
|
||||
노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다.
|
||||
노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과
|
||||
성능 두 가지 측면에서 노드 하트비트를 상당히
|
||||
경제적이도록 해준다.
|
||||
#### 하트비트
|
||||
|
||||
쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
|
||||
하트비트의 두 가지 형태는 `NodeStatus` 와
|
||||
[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다.
|
||||
각 노드에는 `kube-node-lease` 라는
|
||||
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다.
|
||||
리스는 경량 리소스로, 클러스터가 확장될 때
|
||||
노드의 하트비트 성능을 향상 시킨다.
|
||||
|
||||
kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
||||
의무가 있다.
|
||||
|
||||
- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
|
||||
`NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
|
||||
주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
|
||||
보다 훨씬 길다).
|
||||
- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
|
||||
리스 업데이트는 `NodeStatus` 업데이트와는
|
||||
독립적으로 발생한다.
|
||||
|
||||
#### 안정성
|
||||
|
||||
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에
|
||||
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에)
|
||||
|
||||
@@ -64,7 +64,7 @@ card:
|
||||
* **자동화된 복구(self-healing)**
|
||||
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
|
||||
* **시크릿과 구성 관리**
|
||||
쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
|
||||
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
|
||||
|
||||
## 쿠버네티스가 아닌 것
|
||||
|
||||
@@ -74,9 +74,9 @@ card:
|
||||
|
||||
* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
|
||||
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
|
||||
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
|
||||
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
|
||||
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
|
||||
* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
|
||||
* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
|
||||
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
|
||||
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
|
||||
|
||||
|
||||
@@ -0,0 +1,427 @@
|
||||
---
|
||||
title: 서비스와 애플리케이션 연결하기
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
## 컨테이너 연결을 위한 쿠버네티스 모델
|
||||
|
||||
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
|
||||
|
||||
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
|
||||
|
||||
여러 개발자에 걸쳐있는 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 모든 파드에게 자체 클러스터-프라이빗-IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
|
||||
|
||||
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. 동일한 원칙이 보다 완전한 [Jenkins CI 애플리케이션](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)에서 구현된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 파드를 클러스터에 노출하기
|
||||
|
||||
이 작업은 이전 예시에서 수행해 보았지만, 네트워킹 관점을 중점에 두고 다시 한번 수행해 보자.
|
||||
nginx 파드를 생성하고, 해당 파드에 컨테이너 포트 사양이 있는 것을 참고한다.
|
||||
|
||||
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
|
||||
|
||||
이렇게 하면 클러스터의 모든 노드에서 접근할 수 있다. 파드를 실행 중인 노드를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./run-my-nginx.yaml
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
|
||||
my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
|
||||
```
|
||||
|
||||
파드의 IP를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
||||
podIP: 10.244.3.4
|
||||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
|
||||
|
||||
만약 궁금하다면 [우리가 이것을 달성하는 방법](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)을 자세히 읽어본다.
|
||||
|
||||
## 서비스 생성하기
|
||||
|
||||
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
|
||||
|
||||
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
|
||||
|
||||
`kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl expose deployment/my-nginx
|
||||
```
|
||||
```
|
||||
service/my-nginx exposed
|
||||
```
|
||||
|
||||
이것은 다음 yaml 파일을 `kubectl apply -f` 로 실행한 것과 동일하다.
|
||||
|
||||
{{< codenew file="service/networking/nginx-svc.yaml" >}}
|
||||
|
||||
이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을
|
||||
대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다
|
||||
(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는
|
||||
추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는
|
||||
모든 포트일 수 있다).
|
||||
[서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의
|
||||
API 오브젝트를 보고 서비스 정의에서 지원되는 필드 목록을 확인한다.
|
||||
서비스를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-nginx
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
|
||||
```
|
||||
|
||||
앞에서 언급한 바와 같이, 서비스는 파드 그룹에 의해 지원된다. 이 파드들은
|
||||
`endpoints` 를 통해 노출된다. 서비스 셀렉터는 지속적으로 평가되고
|
||||
결과는 `my-nginx` 이름의 엔드포인트 오브젝트에 POST된다.
|
||||
파드가 죽으면 자동적으로 엔드포인트에서 제거되며 서비스 셀렉터와
|
||||
일치하는 새 파드는 자동적으로 엔드포인트에 추가된다.
|
||||
엔드포인트를 확인하고 IP가 첫 번째 단계에서 생성된 파드와 동일하다는
|
||||
점을 참고한다.
|
||||
|
||||
```shell
|
||||
kubectl describe svc my-nginx
|
||||
```
|
||||
```
|
||||
Name: my-nginx
|
||||
Namespace: default
|
||||
Labels: run=my-nginx
|
||||
Annotations: <none>
|
||||
Selector: run=my-nginx
|
||||
Type: ClusterIP
|
||||
IP: 10.0.162.149
|
||||
Port: <unset> 80/TCP
|
||||
Endpoints: 10.244.2.5:80,10.244.3.4:80
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
```shell
|
||||
kubectl get ep my-nginx
|
||||
```
|
||||
```
|
||||
NAME ENDPOINTS AGE
|
||||
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)에 대해 더 읽어본다.
|
||||
|
||||
## 서비스에 접근하기
|
||||
|
||||
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
|
||||
지원한다. 전자는 기본적으로 작동하지만 후자는
|
||||
[CoreDNS 클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
|
||||
{{< note >}}
|
||||
만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
|
||||
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
|
||||
`enableServiceLinks` 플래그를 `false` 로 설정하면 이 모드를 비활성화할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
### 환경 변수들
|
||||
|
||||
파드가 노드에서 실행될 때 kubelet은 각기 활성화된 서비스에 대해 일련의 환경
|
||||
변수 집합을 추가한다. 이것은 순서 문제를 야기한다. 이유를 확인하려면
|
||||
실행 중인 nginx 파드 환경을 점검해야 한다(실제 사용자의 파드 이름은 다를 것이다).
|
||||
|
||||
```shell
|
||||
kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
|
||||
```
|
||||
```
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
|
||||
서비스에 대한 언급이 없다는 것에 참고해야 한다. 이것은 서비스 이전에 레플리카를
|
||||
생성했기 때문이다. 이 작업을 수행할 때 또 다른 단점은 스케줄러가 두 파드를
|
||||
모두 동일한 머신에 배치할 수도 있다는 것이며, 이로 인해 전체 서비스가 중단될 수
|
||||
있다. 두개의 파드를 죽이고 디플로이먼트가 파드를 재생성하기를 기다리는 것으로
|
||||
이를 정상화 할 수 있다. 이번에는 서비스가 레플리카들 *전* 에
|
||||
존재한다. 이렇게 하면 올바른 환경 변수뿐만 아니라 파드의 스케줄러-수준의
|
||||
서비스 분배(모든 노드에 동일한 용량이 제공되는 경우)가
|
||||
된다.
|
||||
|
||||
```shell
|
||||
kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
|
||||
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
|
||||
my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
|
||||
```
|
||||
|
||||
파드가 죽고 재생성되었기 때문에 다른 이름을 가지는 것을 알 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
|
||||
```
|
||||
```
|
||||
KUBERNETES_SERVICE_PORT=443
|
||||
MY_NGINX_SERVICE_HOST=10.0.162.149
|
||||
KUBERNETES_SERVICE_HOST=10.0.0.1
|
||||
MY_NGINX_SERVICE_PORT=80
|
||||
KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
```
|
||||
|
||||
### DNS
|
||||
|
||||
쿠버네티스는 DNS 클러스터 애드온 서비스를 제공하며 dns 이름을 다른 서비스에 자동으로 할당한다. 다음 명령어로 이것이 클러스터에서 실행 중인지 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get services kube-dns --namespace=kube-system
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
|
||||
```
|
||||
|
||||
이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP
|
||||
에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/docs/tasks/administer-cluster/coredns/#installing-coredns)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl run curl --image=radial/busyboxplus:curl -i --tty
|
||||
```
|
||||
```
|
||||
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
|
||||
Hit enter for command prompt
|
||||
```
|
||||
|
||||
이제, `nslookup my-nginx` 를 입력하고 실행한다:
|
||||
|
||||
```shell
|
||||
[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10
|
||||
|
||||
Name: my-nginx
|
||||
Address 1: 10.0.162.149
|
||||
```
|
||||
|
||||
## 서비스 보안
|
||||
|
||||
지금까지는 클러스터 내부에서만 ngnix 서버에 엑세스 해왔다. 서비스를 인터넷에 공개하기 전에 통신 채널이 안전한지 확인해야 한다. 이를 위해선 다음이 필요하다.
|
||||
|
||||
* https에 대한 자체 서명한 인증서 (신원 인증서를 가지고 있지 않은 경우)
|
||||
* 인증서를 사용하도록 구성된 nginx 서버
|
||||
* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/docs/concepts/configuration/secret/)
|
||||
|
||||
[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
|
||||
|
||||
```shell
|
||||
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
|
||||
kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
|
||||
```
|
||||
```
|
||||
secret/nginxsecret created
|
||||
```
|
||||
```shell
|
||||
kubectl get secrets
|
||||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret kubernetes.io/tls 2 1m
|
||||
```
|
||||
그리고 또한 컨피그맵:
|
||||
```shell
|
||||
kubectl create configmap nginxconfigmap --from-file=default.conf
|
||||
```
|
||||
```
|
||||
configmap/nginxconfigmap created
|
||||
```
|
||||
```shell
|
||||
kubectl get configmaps
|
||||
```
|
||||
```
|
||||
NAME DATA AGE
|
||||
nginxconfigmap 1 114s
|
||||
```
|
||||
다음은 make를 실행하는데 문제가 있는 경우에 수행해야 하는 수동 단계이다(예시로 windows).
|
||||
|
||||
```shell
|
||||
# Create a public private key pair
|
||||
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
|
||||
# Convert the keys to base64 encoding
|
||||
cat /d/tmp/nginx.crt | base64
|
||||
cat /d/tmp/nginx.key | base64
|
||||
```
|
||||
이전 명령의 출력을 사용해서 다음과 같이 yaml 파일을 생성한다. base64로 인코딩된 값은 모두 한 줄에 있어야 한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: "v1"
|
||||
kind: "Secret"
|
||||
metadata:
|
||||
name: "nginxsecret"
|
||||
namespace: "default"
|
||||
type: kubernetes.io/tls
|
||||
data:
|
||||
tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
|
||||
tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
|
||||
```
|
||||
이제 파일을 사용해서 시크릿을 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f nginxsecrets.yaml
|
||||
kubectl get secrets
|
||||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret kubernetes.io/tls 2 1m
|
||||
```
|
||||
|
||||
이제 nginx 레플리카를 수정하여 암호화된 인증서를 사용한 https 서버와 서비스를 실행하고, 두 포트(80과 443)를 노출한다.
|
||||
|
||||
{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
|
||||
|
||||
nginx-secure-app의 매니페스트에 대한 주목할만한 점:
|
||||
|
||||
- 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
|
||||
- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
|
||||
는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
|
||||
두 포트를 모두 노출한다.
|
||||
- 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.
|
||||
이것은 nginx 서버가 시작되기 *전에* 설정된 것이다.
|
||||
|
||||
```shell
|
||||
kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
|
||||
```
|
||||
|
||||
이 시점에서 모든 노드에서 nginx 서버에 연결할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -o yaml | grep -i podip
|
||||
podIP: 10.244.3.5
|
||||
node $ curl -k https://10.244.3.5
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
```
|
||||
|
||||
마지막 단계에서 curl에 `-k` 파라미터를 제공한 방법에 참고한다. 이는 인증서 생성시 nginx를 실행하는 파드에 대해 아무것도 모르기 때문에
|
||||
curl에 CName 불일치를 무시하도록 지시해야하기 때문이다. 서비스를 생성해서 인증서에 사용된 CName을 서비스 조회시 파드에서 사용된 실제 DNS 이름과 연결했다.
|
||||
파드에서 이것을 테스트 해보자(단순히 동일한 시크릿이 재사용되고 있으며, 파드는 서비스에 접근하기위해 nginx.crt만 필요하다).
|
||||
|
||||
{{< codenew file="service/networking/curlpod.yaml" >}}
|
||||
|
||||
```shell
|
||||
kubectl apply -f ./curlpod.yaml
|
||||
kubectl get pods -l app=curlpod
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
curl-deployment-1515033274-1410r 1/1 Running 0 1m
|
||||
```
|
||||
```shell
|
||||
kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
|
||||
...
|
||||
<title>Welcome to nginx!</title>
|
||||
...
|
||||
```
|
||||
|
||||
## 서비스 노출하기
|
||||
|
||||
애플리케이션의 일부인 경우 원한다면 외부 IP 주소에 서비스를
|
||||
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
|
||||
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
|
||||
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
|
||||
준비가 되어있다.
|
||||
|
||||
```shell
|
||||
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
|
||||
uid: 07191fb3-f61a-11e5-8ae5-42010af00002
|
||||
spec:
|
||||
clusterIP: 10.0.162.149
|
||||
ports:
|
||||
- name: http
|
||||
nodePort: 31704
|
||||
port: 8080
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
- name: https
|
||||
nodePort: 32453
|
||||
port: 443
|
||||
protocol: TCP
|
||||
targetPort: 443
|
||||
selector:
|
||||
run: my-nginx
|
||||
```
|
||||
```shell
|
||||
kubectl get nodes -o yaml | grep ExternalIP -C 1
|
||||
- address: 104.197.41.11
|
||||
type: ExternalIP
|
||||
allocatable:
|
||||
--
|
||||
- address: 23.251.152.56
|
||||
type: ExternalIP
|
||||
allocatable:
|
||||
...
|
||||
|
||||
$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
```
|
||||
|
||||
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
|
||||
|
||||
```shell
|
||||
kubectl edit svc my-nginx
|
||||
kubectl get svc my-nginx
|
||||
```
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
|
||||
```
|
||||
```
|
||||
curl https://<EXTERNAL-IP> -k
|
||||
...
|
||||
<title>Welcome to nginx!</title>
|
||||
```
|
||||
|
||||
`EXTERNAL-IP` 의 IP 주소는 공용 인터넷에서 이용할 수 있는 주소이다. `CLUSTER-IP` 는
|
||||
클러스터/프라이빗 클라우드 네트워크 내에서만 사용할 수 있다.
|
||||
|
||||
AWS에서는 `LoadBalancer` 유형은 IP가 아닌 (긴)호스트네임을 사용하는 ELB를
|
||||
생성한다는 점을 참고한다. 이것은 일반적인 `kubectl get svc` 의 출력에
|
||||
맞추기에는 매우 길기 때문에 실제로 이를 보려면 `kubectl describe service my-nginx` 를
|
||||
수행해야 한다. 다음과 같은 것을 보게 된다.
|
||||
|
||||
```shell
|
||||
kubectl describe service my-nginx
|
||||
...
|
||||
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
|
||||
...
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
게다가 쿠버네티스는 여러 클러스터와 클라우드 공급자들을 포괄하는
|
||||
페더레이션 서비스를 지원하여 가용성을 높이고 내결함성을 향상시키며,
|
||||
보다 큰 서비스의 확장성을 제공한다. 자세한 내용은
|
||||
[페더레이션 서비스 사용자 가이드](/docs/concepts/cluster-administration/federation-service-discovery/)
|
||||
를 본다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -12,7 +12,7 @@ weight: 10
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
|
||||
|
||||
_엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
|
||||
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
|
||||
@@ -24,7 +24,7 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
|
||||
|
||||
## 엔드포인트 슬라이스 리소스 {#endpointslice-resource}
|
||||
|
||||
쿠버네티스에서 엔드포인트 슬라이스는 일련의 네트워크 엔드 포인트에 대한
|
||||
쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
|
||||
참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice
|
||||
컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는
|
||||
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트
|
||||
@@ -34,13 +34,13 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
|
||||
리소스 샘플이 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1alpha1
|
||||
apiVersion: discovery.k8s.io/v1beta1
|
||||
kind: EndpointSlice
|
||||
metadata:
|
||||
name: example-abc
|
||||
labels:
|
||||
kubernetes.io/service-name: example
|
||||
addressType: IP
|
||||
addressType: IPv4
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
@@ -48,7 +48,6 @@ ports:
|
||||
endpoints:
|
||||
- addresses:
|
||||
- "10.1.2.3"
|
||||
- "2001:db8::1234:5678"
|
||||
conditions:
|
||||
ready: true
|
||||
hostname: pod-1
|
||||
@@ -65,6 +64,14 @@ endpoints:
|
||||
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
|
||||
서비스에 대해 성능 향상을 제공해야 한다.
|
||||
|
||||
## 주소 유형
|
||||
|
||||
EndpointSlice는 다음 주소 유형을 지원한다.
|
||||
|
||||
* IPv4
|
||||
* IPv6
|
||||
* FQDN (Fully Qualified Domain Name)
|
||||
|
||||
## 사용동기
|
||||
|
||||
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
|
||||
|
||||
@@ -55,7 +55,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [인그레스](/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
|
||||
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
|
||||
* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -44,7 +44,7 @@ weight: 40
|
||||
[ Services ]
|
||||
```
|
||||
|
||||
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
|
||||
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
|
||||
|
||||
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
|
||||
[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
|
||||
@@ -52,10 +52,10 @@ weight: 40
|
||||
|
||||
## 전제 조건들
|
||||
|
||||
[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
|
||||
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
|
||||
|
||||
[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러
|
||||
[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
|
||||
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
|
||||
|
||||
이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스
|
||||
컨트롤러는 조금 다르게 작동한다.
|
||||
@@ -89,7 +89,7 @@ spec:
|
||||
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
|
||||
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
|
||||
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
|
||||
다른 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
||||
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
||||
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
|
||||
|
||||
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
||||
@@ -117,7 +117,7 @@ spec:
|
||||
### 기본 벡엔드
|
||||
|
||||
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
|
||||
백엔드는 일반적으로 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
|
||||
백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
|
||||
|
||||
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
|
||||
기본 백엔드로 라우팅 된다.
|
||||
@@ -218,7 +218,7 @@ Events:
|
||||
볼 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
사용중인 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)
|
||||
사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
|
||||
에 따라 default-http-backend
|
||||
[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
|
||||
{{< /note >}}
|
||||
@@ -452,7 +452,7 @@ Events:
|
||||
## 가용성 영역에 전체에서의 실패
|
||||
|
||||
장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
|
||||
자세한 내용은 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
|
||||
자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
|
||||
를 참조할 수 있다.
|
||||
|
||||
## 앞으로의 할일
|
||||
@@ -472,6 +472,6 @@ Events:
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
|
||||
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
|
||||
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: 서비스 토폴로지
|
||||
feature:
|
||||
title: 서비스 토폴로지
|
||||
description: >
|
||||
클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅.
|
||||
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
|
||||
|
||||
_서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
|
||||
기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
|
||||
클라이언트와 동일한 노드이거나 동일한 가용성 영역에 있는 엔드포인트로
|
||||
우선적으로 라우팅되도록 지정할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 소개
|
||||
|
||||
기본적으로 `ClusterIP` 또는 `NodePort` 서비스로 전송된 트래픽은 서비스의
|
||||
모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)"
|
||||
트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만,
|
||||
`ClusterIP` 서비스에서는 지원되지 않으며 더 복잡한
|
||||
토폴로지 — 영역별 라우팅과 같은 — 에서는 불가능 했다.
|
||||
_서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서
|
||||
노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록
|
||||
함으로써 이 문제를 해결한다.
|
||||
|
||||
소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에
|
||||
적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)"
|
||||
노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을
|
||||
동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는
|
||||
지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다.
|
||||
다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로
|
||||
트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(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"
|
||||
```
|
||||
|
||||
## 서비스 토폴로지 사용하기
|
||||
|
||||
만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서
|
||||
`topologyKeys` 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
|
||||
이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
|
||||
레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
|
||||
발신 노드 값과 일치하는 노드로 보내진다. 만약 노드에 서비스와 일치하는
|
||||
백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
|
||||
레이블이 남지 않을 때까지 고려한다.
|
||||
|
||||
만약 일치하는 것을 못찾는 경우에는, 서비스에 대한 백엔드가 없었던 것처럼
|
||||
트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
|
||||
토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
|
||||
클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
|
||||
대한 백엔드가 없기에 연결에 실패해야 한다. 특수한 값인 `"*"` 은 "모든 토폴로지"를
|
||||
의미하는데 사용될 수 있다. 이 캐치 올(catch-all) 값을 사용하는 경우
|
||||
목록의 마지막 값으로만 타당하다.
|
||||
|
||||
만약 `topologyKeys` 가 지정되지 않거나 비어있는 경우 토폴로지 제약 조건이 적용되지 않는다.
|
||||
|
||||
호스트 이름, 영역 이름 그리고 지역 이름으로 레이블이 지정된 노드가 있는
|
||||
클러스터가 있다고 생각해 보자. 그러고 나면, 서비스의 `topologyKeys` 값을 설정해서 다음과 같이 트래픽을
|
||||
전달할 수 있다.
|
||||
|
||||
* 동일한 노드의 엔드포인트에만 해당하고, 엔드포인트가 노드에 없으면 실패한다:
|
||||
`["kubernetes.io/hostname"]`.
|
||||
* 동일한 노드의 엔드포인트를 선호하지만, 동일한 영역의 엔드포인트로 대체
|
||||
한 후 동일한 지역으로 대체되고, 그렇지 않으면 실패한다: `["kubernetes.io/hostname",
|
||||
"topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`.
|
||||
예를 들어 데이터 위치가 중요한 경우에 유용할 수 있다.
|
||||
* 동일한 영역이 선호되지만, 이 영역 내에 사용할 수 있는 항목이 없는 경우에는
|
||||
사용가능한 엔드포인트로 대체된다:
|
||||
`["topology.kubernetes.io/zone", "*"]`.
|
||||
|
||||
|
||||
|
||||
## 제약들
|
||||
|
||||
* 서비스 토폴로지는 `externalTrafficPolicy=Local` 와 호환되지 않으므로
|
||||
서비스는 이 두 가지 기능을 함께 사용할 수 없다. 동일한 서비스가 아닌
|
||||
같은 클러스터의 다른 서비스라면 이 기능을 함께 사용할
|
||||
수 있다.
|
||||
|
||||
* 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
|
||||
`topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
|
||||
제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
|
||||
|
||||
* 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.
|
||||
|
||||
* 만약 캐치 올(catch-all) 값인 `"*"` 를 사용한다면 토폴로지 키들의 마지막 값이어야
|
||||
한다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다.
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
|
||||
|
||||
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
|
||||
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
|
||||
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [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/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
- 모든 노드에서 [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/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
|
||||
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
|
||||
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
|
||||
@@ -95,21 +95,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
|
||||
## 데몬 파드가 스케줄 되는 방법
|
||||
|
||||
### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함)
|
||||
### 기본 스케줄러로 스케줄
|
||||
|
||||
일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋
|
||||
컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이
|
||||
파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다.
|
||||
|
||||
- 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리)
|
||||
필드를 존중하지 않는다.
|
||||
- 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을
|
||||
도울 수도 있다.
|
||||
|
||||
|
||||
### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용)
|
||||
|
||||
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
|
||||
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
|
||||
|
||||
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
|
||||
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
|
||||
|
||||
@@ -44,10 +44,6 @@ weight: 40
|
||||
## 구성 요소
|
||||
아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
|
||||
|
||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -99,6 +95,12 @@ spec:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
위의 예시에서:
|
||||
|
||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||
|
||||
## 파드 셀렉터
|
||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||
|
||||
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
|
||||
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
|
||||
|
||||
{{< note >}}
|
||||
클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
|
||||
클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
|
||||
아니라면 `cluster.local`로 설정된다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
|
||||
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
|
||||
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
|
||||
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
|
||||
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
||||
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
|
||||
처리하도록 확장될 수 있다.
|
||||
|
||||
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고
|
||||
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`TTLAfterFinished` 를 통해 활성화 될 수 있다.
|
||||
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
|
||||
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -144,7 +144,7 @@ spec:
|
||||
+---------------+-------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+
|
||||
| node1 | node2 | nod3 |
|
||||
| node1 | node2 | node3 |
|
||||
+-------+-------+-------+
|
||||
| P P | P | P P |
|
||||
+-------+-------+-------+
|
||||
|
||||
Reference in New Issue
Block a user