diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 43a6a82343..9e7c9b4fc7 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -26,9 +26,9 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 -kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 -[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다. +[여기](/ko/docs/reference/kubectl/cheatsheet/)에서 +kubectl 사용 예시를 볼 수 있으며, 완전한 문서는 +[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다. ## REST API에 직접 접근 @@ -44,12 +44,12 @@ REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 - 앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다. - 직접적으로 http 클라이언트에 위치정보와 인증정보를 제공. - 대안적인 접근 방식. - - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 code들과 같이 동작한다. - - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 import해야 한다. + - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 코드와 같이 동작한다. + - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 임포트해야 한다. ### kubectl proxy 사용 -다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 +다음 커맨드는 kubectl을 리버스 프록시(reverse proxy)처럼 동작하는 모드를 실행한다. 이는 apiserver의 위치지정과 인증을 처리한다. 다음과 같이 실행한다. @@ -205,7 +205,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, 컨테이너 내부에서 백그라운드 프로세스로 실행한다. - 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 + 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) @@ -215,47 +215,47 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/ko/docs/concepts/architecture/nodes/), -[파드들](/ko/docs/concepts/workloads/pods/), -[서비스들](/ko/docs/concepts/services-networking/service/)은 -모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 +쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. + +쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), +[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 +고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을 할 수 없을 것이다. ### 통신을 위한 방식들 -클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. +클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - 공인 IP를 통해 서비스에 접근. - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 - 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 - 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. + - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 + 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다. - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 접근할 필요는 없다. - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 + 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. + - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - 클러스터 내 노드 또는 파드에서 접근. - - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. - 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. + - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. + 해당 셸에서 다른 노드, 파드, 서비스에 연결한다. - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. -### 빌트인 서비스들의 발견 +### 빌트인 서비스 검색 -일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. -`kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다. +일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. +`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. ```shell kubectl cluster-info @@ -280,20 +280,20 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi #### 수작업으로 apiserver proxy URL을 구축 -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. -당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. +당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다. -기본적으로 API server는 http를 사용하여 서비스를 proxy한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. +기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` URL의 네임 부분에 지원되는 양식은 다음과 같다. -* `` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다 -* `:` - http를 사용하여 지정된 port로 proxy한다 -* `https::` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의) -* `https::` - https를 사용하여 지정된 port로 proxy한다 +* `` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. +* `:` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. +* `https::` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의) +* `https::` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. ##### 예제들 @@ -326,38 +326,38 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. ## 요청 redirect -redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy를 사용하기를 바란다. +redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다. -## 다양한 Proxy들 +## 다양한 프록시들 -쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다. +쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 프록시들이 존재한다. 1. [kubectl proxy](#rest-api에-직접-접근): - 사용자의 데스크탑이나 파드 내에서 실행한다 - - localhost 주소에서 쿠버네티스 apiserver로 proxy한다 - - proxy하는 클라이언트는 HTTP를 사용한다 - - apiserver의 proxy는 HTTPS를 사용한다 + - localhost 주소에서 쿠버네티스 apiserver로 프록시한다 + - 프록시하는 클라이언트는 HTTP를 사용한다 + - apiserver의 프록시는 HTTPS를 사용한다 - apiserver를 위치지정한다 - 인증 header들을 추가한다 -1. [apiserver proxy](#빌트인-서비스들의-발견): +1. [apiserver proxy](#빌트인-서비스-검색): - apiserver 내의 빌트인 bastion이다 - - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP들로 연결한다 + - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP로 연결한다 - apiserver process들 내에서 실행된다 - - proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) - - 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 + - 프록시하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) + - 타겟으로의 프록시는 가용정보를 사용하는 프록시에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 - 서비스에 접근하는 데 사용되면 load balacing한다 1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드 상에서 실행된다 - - UDP와 TCP를 proxy한다 + - UDP와 TCP를 프록시한다 - HTTP를 인지하지 않는다 - load balancing을 제공한다 - - 서비스에 접근하는 데만 사용된다 + - 서비스에 접근하는 데에만 사용된다 1. apiserver(s) 전면의 Proxy/Load-balancer: diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index a6739cc2ea..cc5f872cc5 100644 --- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -8,7 +8,7 @@ min-kubernetes-server-version: v1.10 이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서 -실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스 +실행중인 MongoDB 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스 디버깅에 유용할 수 있다. @@ -19,25 +19,25 @@ min-kubernetes-server-version: v1.10 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* [redis-cli](http://redis.io/topics/rediscli)를 설치한다. +* [MongoDB Shell](https://www.mongodb.com/try/download/shell)을 설치한다. -## Redis 디플로이먼트와 서비스 생성하기 +## MongoDB 디플로이먼트와 서비스 생성하기 -1. Redis를 실행하기 위해 디플로이먼트를 생성한다. +1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml ``` 성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다. ``` - deployment.apps/redis-master created + deployment.apps/mongo created ``` 파드 상태를 조회하여 파드가 준비되었는지 확인한다. @@ -49,8 +49,8 @@ min-kubernetes-server-version: v1.10 출력은 파드가 생성되었다는 것을 보여준다. ``` - NAME READY STATUS RESTARTS AGE - redis-master-765d459796-258hz 1/1 Running 0 50s + NAME READY STATUS RESTARTS AGE + mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s ``` 디플로이먼트 상태를 조회한다. @@ -62,64 +62,65 @@ min-kubernetes-server-version: v1.10 출력은 디플로이먼트가 생성되었다는 것을 보여준다. ``` - NAME READY UP-TO-DATE AVAILABLE AGE - redis-master 1/1 1 1 55s + NAME READY UP-TO-DATE AVAILABLE AGE + mongo 1/1 1 1 2m21s ``` + 디플로이먼트는 자동으로 레플리카셋을 관리한다. 아래의 명령어를 사용하여 레플리카셋 상태를 조회한다. ```shell - kubectl get rs + kubectl get replicaset ``` 출력은 레플리카셋이 생성되었다는 것을 보여준다. ``` - NAME DESIRED CURRENT READY AGE - redis-master-765d459796 1 1 1 1m + NAME DESIRED CURRENT READY AGE + mongo-75f59d57f4 1 1 1 3m12s ``` -2. Redis를 네트워크에 노출시키기 위해 서비스를 생성한다. +2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` 성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다. ``` - service/redis-master created + service/mongo created ``` 서비스가 생성되었는지 확인한다. ```shell - kubectl get svc | grep redis + kubectl get service mongo ``` 출력은 서비스가 생성되었다는 것을 보여준다. ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - redis-master ClusterIP 10.0.0.213 6379/TCP 27s + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + mongo ClusterIP 10.96.41.183 27017/TCP 11s ``` -3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다. +3. MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다. ```shell - # redis-master-765d459796-258hz 를 파드 이름으로 변경한다. - kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' ``` - 출력은 파드 내 Redis 포트 번호를 보여준다. + 출력은 파드 내 MongoDB 포트 번호를 보여준다. ``` - 6379 + 27017 ``` - (이 TCP 포트는 Redis가 인터넷에 할당된 것이다). + (이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.) ## 파드의 포트를 로컬 포트로 포워딩하기 @@ -127,39 +128,39 @@ min-kubernetes-server-version: v1.10 ```shell - # redis-master-765d459796-258hz 를 파드 이름으로 변경한다. - kubectl port-forward redis-master-765d459796-258hz 7000:6379 + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 ``` 이것은 ```shell - kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379 + kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 ``` 또는 ```shell - kubectl port-forward deployment/redis-master 7000:6379 + kubectl port-forward deployment/mongo 28015:27017 ``` 또는 ```shell - kubectl port-forward rs/redis-master 7000:6379 + kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 ``` 또는 다음과 같다. ```shell - kubectl port-forward service/redis-master 7000:redis + kubectl port-forward service/mongo 28015:27017 ``` 위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다. ``` - Forwarding from 127.0.0.1:7000 -> 6379 - Forwarding from [::1]:7000 -> 6379 + Forwarding from 127.0.0.1:28015 -> 27017 + Forwarding from [::1]:28015 -> 27017 ``` {{< note >}} @@ -168,22 +169,22 @@ min-kubernetes-server-version: v1.10 {{< /note >}} -2. Redis 커맨드라인 인터페이스를 실행한다. +2. MongoDB 커맨드라인 인터페이스를 실행한다. ```shell - redis-cli -p 7000 + mongosh --port 28015 ``` -3. Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다. +3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다. ```shell - ping + db.runCommand( { ping: 1 } ) ``` 성공적인 핑 요청을 반환한다. ``` - PONG + { ok: 1 } ``` ### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port} @@ -193,15 +194,15 @@ min-kubernetes-server-version: v1.10 부담을 줄일 수 있다. ```shell -kubectl port-forward deployment/redis-master :6379 +kubectl port-forward deployment/mongo :27017 ``` -`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는 -다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다. +`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다 (낮은 포트 번호는 +다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서). 출력은 다음과 같을 것이다. ``` -Forwarding from 127.0.0.1:62162 -> 6379 -Forwarding from [::1]:62162 -> 6379 +Forwarding from 127.0.0.1:63753 -> 27017 +Forwarding from [::1]:63753 -> 27017 ``` @@ -209,7 +210,7 @@ Forwarding from [::1]:62162 -> 6379 ## 토의 -로컬 7000 포트에 대한 연결은 Redis 서버가 실행중인 파드의 6379 포트로 포워딩된다. +로컬 28015 포트에 대한 연결은 MongoDB 서버가 실행중인 파드의 27017 포트로 포워딩된다. 이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데 사용할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 5dd7a627d0..8019e46c25 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -19,22 +19,22 @@ content_type: task 쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 -고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수 -없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서 -도달할 수 없다. +고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 +접근할 수 없을 것이다. ### 연결하는 방법 -클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다. +클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - 퍼블릭 IP를 통해 서비스에 접근한다. - - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서 - 접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와 + - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 + 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다. - - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며, - 인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다. - 자체 인증을 수행하는가? - - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, + - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + 해당 서비스는 자체적으로 인증을 수행하는가? + - 파드는 서비스 뒤에 위치시킨다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, 파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다. - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접 접근할 필요는 없다. @@ -54,8 +54,8 @@ content_type: task ### 빌트인 서비스 검색 -일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을 -사용하여 이들의 목록을 얻는다. +일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. +`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. ```shell kubectl cluster-info diff --git a/content/ko/docs/tasks/administer-cluster/coredns.md b/content/ko/docs/tasks/administer-cluster/coredns.md index 6f0caad9e4..414f681901 100644 --- a/content/ko/docs/tasks/administer-cluster/coredns.md +++ b/content/ko/docs/tasks/administer-cluster/coredns.md @@ -33,8 +33,8 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트 ### Kubeadm을 사용해 기존 클러스터 업그레이드하기 쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여 -`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은 -`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의 +`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은 +`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의 설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다. 만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다. @@ -44,8 +44,6 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true ``` 쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다. -업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 -설명된 지침 가이드를 참고하자. 1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**. **만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이 @@ -54,26 +52,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true 만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서, 기존의 Corefile이 유지된다. - -### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기 - -{{< note >}} -쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며, -기본적으로 설치된다. -{{< /note >}} - -{{< warning >}} -쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. -{{< /warning >}} - -1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` -값을 `false` 로 변경해야 한다. - -``` -kubeadm init --feature-gates=CoreDNS=false -``` - -1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자. +쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다. ## CoreDNS 업그레이드하기 diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index ad76009844..9521bb1ec6 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -31,7 +31,7 @@ DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. {{< note >}} -CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. +CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. 이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. {{< /note >}} @@ -176,17 +176,14 @@ kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 CoreDNS는 kube-dns 이상의 기능을 지원한다. `StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다. -마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다. ### 예시 -kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다. +kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다. ```yaml apiVersion: v1 data: - federations: | - {"foo" : "foo.feddomain.com"} stubDomains: | {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} upstreamNameservers: | @@ -196,13 +193,6 @@ kind: ConfigMap CoreDNS에서는 동등한 설정으로 Corefile을 생성한다. -* federations 에 대응하는 설정: -``` -federation cluster.local { - foo foo.feddomain.com -} -``` - * stubDomains 에 대응하는 설정: ```yaml abc.com:53 { diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 487d89379e..3474aee3c2 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -168,7 +168,7 @@ controllerManager: ### 인증서 서명 요청(CSR) 생성 -쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다. +쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다. ## 외부 CA로 인증서 갱신 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index bf70b98e93..2227c49c9e 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -37,7 +37,7 @@ weight: 20 ### 추가 정보 -- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이 +- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이 필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다. - 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다. @@ -328,7 +328,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, - 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다. - 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다. - 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다. -- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다. +- 새로운 `CoreDNS` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다. - API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다. `kubeadm upgrade node` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index bee3c94069..25abb14314 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -18,7 +18,7 @@ weight: 10 **사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). -1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다. +1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가한다. **문법** ```shell diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 4daf739c2f..aea2fcffa1 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -31,21 +31,14 @@ API 서버에서 제어될 수는 없다. 을 사용하는 것이 바람직하다. {{< /note >}} - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. - - - - ## 스태틱 파드 생성하기 {#static-pod-creation} @@ -54,7 +47,9 @@ API 서버에서 제어될 수는 없다. ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} -매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. +[kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)의 `staticPodPath: ` 필드를 사용하자. +명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. @@ -90,17 +85,18 @@ Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단 3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. - ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" - ``` - 혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: ` 필드를 추가한다. + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 혹은 [kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)에 + `staticPodPath: ` 필드를 추가한다. 4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. - ```shell - # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. - systemctl restart kubelet - ``` + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` ### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 2c7a95a136..f8696993ff 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -57,7 +57,7 @@ kubectl describe pods ${POD_NAME} 절대 스케줄 될 수 없다. 사용자는 `kubectl get nodes -o ` 명령으로 노드의 - 용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지 + 용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지 명령의 예이다. ```shell diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md index e2b1435464..4addcdcfaf 100644 --- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -1,12 +1,16 @@ --- title: 크론잡(CronJob)으로 자동화된 작업 실행 -min-kubernetes-server-version: v1.8 +min-kubernetes-server-version: v1.21 content_type: task weight: 10 --- +쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다. +이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다. +이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다. + 시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다. 이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다. @@ -168,13 +172,11 @@ kubectl delete cronjob hello 이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다. 이 필드를 지정하지 않으면, 잡에 기한이 없다. -크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다. +`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면, +크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고, +시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다. -예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다. - -`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다. - -예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다. +예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다. ### 동시성 정책 diff --git a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md index fa765a7005..bd8bf38808 100644 --- a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: 작업 대기열을 사용한 거친 병렬 처리 min-kubernetes-server-version: v1.8 content_type: task -weight: 30 +weight: 20 --- @@ -19,7 +19,7 @@ weight: 30 1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도 된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다. 1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. - 이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다. + 이 예제에서, 메시지는 긴 계산을 수행할 정수다. 1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는 메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다. @@ -141,13 +141,12 @@ root@temp-loe07:/# ``` 마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를 -받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 -받은 값을 바로 출력하고 있고, echo가 캐리지 리턴을 더해주어 +받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 받은 값을 출력하고, echo가 캐리지 리턴을 더해주어 출력 결과가 보여진다. ## 작업으로 대기열 채우기 -이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을 +이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을 출력하는 것이다. 실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다. diff --git a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md index 8788477c17..b85f687df7 100644 --- a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: 작업 대기열을 사용한 정밀 병렬 처리 content_type: task min-kubernetes-server-version: v1.8 -weight: 40 +weight: 30 --- @@ -21,7 +21,7 @@ weight: 40 않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는 Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다. 1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이 - 예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다. + 예에서, 메시지는 긴 계산을 수행할 정수다. 1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는 메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.