kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[ko] Update outdated files in dev-1.21-ko.1 (p2)

This commit is contained in:
Jihoon Seo 2021-04-14 15:09:48 +09:00
parent 839722d85b
commit 6a38fb4f2d
13 changed files with 138 additions and 171 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
content/ko/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -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의 네임 부분에 지원되는 양식은 다음과 같다.
* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다
* `<service_name>:<port_name>` - http를 사용하여 지정된 port로 proxy한다
* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의)
* `https:<service_name>:<port_name>` - https를 사용하여 지정된 port로 proxy한다
* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
* `<service_name>:<port_name>` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의)
* `https:<service_name>:<port_name>` - 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:

89
content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
View File

@ -8,7 +8,7 @@ min-kubernetes-server-version: v1.10
<!-- overview -->
이 페이지는 `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)을 설치한다.
<!-- steps -->
## 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 <none> 6379/TCP 27s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mongo ClusterIP 10.96.41.183 <none> 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 포트로 포워딩된다.
이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
사용할 수 있다.

24
content/ko/docs/tasks/administer-cluster/access-cluster-services.md
View File

@ -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

27
content/ko/docs/tasks/administer-cluster/coredns.md
View File

@ -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 업그레이드하기

14
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
View File

@ -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 {

2
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
View File

@ -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로 인증서 갱신

4
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -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` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다.

2
content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
View File

@ -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

28
content/ko/docs/tasks/configure-pod-container/static-pod.md
View File

@ -31,21 +31,14 @@ API 서버에서 제어될 수는 없다.
을 사용하는 것이 바람직하다.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
<!-- steps -->
## 스태틱 파드 생성하기 {#static-pod-creation}
@ -54,7 +47,9 @@ API 서버에서 제어될 수는 없다.
### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다.
[kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)의 `staticPodPath: <the directory>` 필드를 사용하자.
명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 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: <the directory>` 필드를 추가한다.
```
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: <the directory>` 필드를 추가한다.
4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다.
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
```shell
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
systemctl restart kubelet
```
### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http}

2
content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
View File

@ -57,7 +57,7 @@ kubectl describe pods ${POD_NAME}
절대 스케줄 될 수 없다.
사용자는 `kubectl get nodes -o <format>` 명령으로 노드의
용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지
용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지
명령의 예이다.
```shell

16
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
View File

@ -1,12 +1,16 @@
---
title: 크론잡(CronJob)으로 자동화된 작업 실행
min-kubernetes-server-version: v1.8
min-kubernetes-server-version: v1.21
content_type: task
weight: 10
---
<!-- overview -->
쿠버네티스 버전 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초까지는 잡이 생성될 수 있다.
### 동시성 정책

9
content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
View File

@ -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가 캐리지 리턴을 더해주어
출력 결과가 보여진다.
## 작업으로 대기열 채우기
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을
이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을
출력하는 것이다.
실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다.

4
content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md
View File

@ -2,7 +2,7 @@
title: 작업 대기열을 사용한 정밀 병렬 처리
content_type: task
min-kubernetes-server-version: v1.8
weight: 40
weight: 30
---
<!-- overview -->
@ -21,7 +21,7 @@ weight: 40
않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는
Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다.
1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이
예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다.
예에서, 메시지는 긴 계산을 수행할 정수다.
1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는
메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다.