Ninth Korean l10n work for release 1.18

- Fix error in k8s.io/ko/docs/concepts/workloads/pods/pod-lifecycle/ (#22681)
- Translate docs/reference/setup-tools/kubeadm/kubeadm.md in Korean (#22684)
- Update outdated files in dev-1.18-ko.9 branch (#22686)
- Fix issues of ko-doc links in translated docs (#22718)
- Translate concepts/cluster-administration/monitoring.md into Korean (#22808)
- Translate tasks/access-application-cluster/service-access-application-cluster in Korean (#22800)
- Translate concepts/storage/storage-limits.md into Korean (#22795)

Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr>
Co-authored-by: Reung37 <reung37@naver.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
Jihoon Seo
2020-07-24 11:09:21 +09:00
committed by Seokho Son
parent cac85d2bb2
commit e2ea8ff0f3
75 changed files with 795 additions and 337 deletions
@@ -15,12 +15,12 @@ content_type: concept
## 처음이라면 kubectl을 사용하여 액세스
최초로 쿠버네티스 API에 액세스할 때 우리는
최초로 쿠버네티스 API에 액세스할 때 우리는
쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다.
클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
인증정보를 가져야 한다. 일반적으로 이는 당신이
[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한
인증정보를 가져야 한다. 일반적으로 이는 당신이
[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나,
다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다.
@@ -29,13 +29,13 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
kubectl config view
```
많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며
완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.
## REST API에 직접 액세스
kubectl은 apiserver의 위치 파악과 인증을 처리한다.
만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
kubectl은 apiserver의 위치 파악과 인증을 처리한다.
만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로
REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다.
- kubectl을 proxy 모드로 실행.
@@ -51,8 +51,8 @@ REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하
### kubectl proxy 사용
다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는
apiserver의 위치지정과 인증을 처리한다.
다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는
apiserver의 위치지정과 인증을 처리한다.
다음과 같이 실행한다.
```shell
@@ -61,7 +61,7 @@ kubectl proxy --port=8080
상세 내용은 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참조한다
이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는
이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는
IPv6 주소 [::1]로도 대체할 수 있다.
```shell
@@ -142,22 +142,22 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
}
```
위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로
두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을
위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로
두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을
서버 접속에 사용한다.
(이들은 `~/.kube` 디렉터리에 설치된다.)
일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가
(이들은 `~/.kube` 디렉터리에 설치된다.)
일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가
root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.
localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
요구하지 않지만 이는 표준이 아니다.
localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을
요구하지 않지만 이는 표준이 아니다.
[Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다.
이 방식들은 미래의 고가용성 지원과 충돌될 수 있다.
## API에 프로그래밍 방식으로 액세스
쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트)
클라이언트 라이브러리를 지원한다.
### Go 클라이언트
@@ -165,7 +165,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터
* 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다.
* client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다.
Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
[예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다.
@@ -174,7 +174,7 @@ Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동
Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다.
Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다.
[예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다.
### 다른 언어
@@ -184,44 +184,44 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와
## 파드에서 API 액세스
파드에서 API를 접속한다면 apiserver의
파드에서 API를 접속한다면 apiserver의
위치지정과 인증은 다소 다르다.
파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은
`kubernetes.default.svc` DNS 네임을 사용하는 것이다.
파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은
`kubernetes.default.svc` DNS 네임을 사용하는 것이다.
이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다.
apiserver 인증에 추천되는 방식은
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며
해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의
apiserver 인증에 추천되는 방식은
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며
해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의
`/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다.
사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며
사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며
apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의
마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다.
파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다.
- 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나,
컨테이너 내부에서 백그라운드 프로세스로 실행한다.
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여
- 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나,
컨테이너 내부에서 백그라운드 프로세스로 실행한다.
이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여
해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다.
- Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()``kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다.
- Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()``kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다.
이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다.
## 클러스터에서 실행되는 서비스로 액세스
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서
[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은
모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을
할 수 없을 것이다.
### 통신을 위한 방식들
@@ -229,33 +229,33 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다.
- 공인 IP를 통해 서비스에 액세스.
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/docs/user-guide/services)와
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/docs/user-guide/services)와
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
- 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
- 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나
인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
해당 서비스는 자체적으로 인증을 수행하는가?
- 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
- 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다.
- 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
- 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
액세스할 필요는 없다.
- Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스.
- 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
- 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에
액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다.
- 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다.
- HTTP/HTTPS에서만 동작한다.
- [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
- 클러스터 내 노드 또는 파드에서 액세스.
- 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
- 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다.
- 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
- 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
### 빌트인 서비스들의 발견
일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다.
일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다.
`kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다.
```shell
@@ -273,15 +273,15 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다.
예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다.
(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
#### 수작업으로 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* 을 지정할 필요는 없다.
@@ -300,7 +300,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
* Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
```json
{
"cluster_name" : "kubernetes_logging",
@@ -320,9 +320,9 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다.
브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
- 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
- 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다.
- 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
- 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다.
## 요청 redirect
@@ -373,7 +373,5 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy
- UDP/TCP 만 사용한다
- cloud provider마다 구현된 내용이 상이하다
일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는
나머지 타입을 적절하게 구성해줘야 한다.
@@ -8,6 +8,4 @@ content_type: concept
쿠버네티스는 지원하는 모든 환경에서 기본으로 활성화된 DNS 클러스터 애드온을 제공한다. 쿠버네티스 1.11과 이후 버전에서는, CoreDNS가 권장되고 기본적으로 kubeadm과 함께 설치 된다.
<!-- body -->
쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다.
쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다.
@@ -0,0 +1,158 @@
---
title: 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기
content_type: tutorial
weight: 60
---
<!-- overview -->
이 문서는 외부 클라이언트가 클러스터에서 실행 중인 애플리케이션에 접근하기
위해 사용하는 쿠버네티스 서비스 오브젝트를 생성하는 방법을 설명한다. 서비스는
실행 중인 두 개의 인스턴스를 갖는 애플리케이션에 대한 로드 밸런싱을 제공한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
## {{% heading "objectives" %}}
* Hello World 애플리케이션 인스턴스 두 개를 실행한다.
* 노드 포트를 노출하는 서비스 오브젝트를 생성한다.
* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다.
<!-- lessoncontent -->
## 두 개의 파드에서 실행 중인 애플리케이션에 대한 서비스 생성하기
다음은 애플리케이션 디플로이먼트(Deployment) 설정 파일이다.
{{< codenew file="service/access/hello-application.yaml" >}}
1. 클러스터 내 Hello World 애플리케이션을 실행하자.
위 파일을 사용하여 애플리케이션 디플로이먼트를 생성하자.
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
앞의 명령은
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
오브젝트와 연관된
[레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
오브젝트를 생성한다. 레플리카셋은 두 개의
[파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고,
각각은 Hello World 애플리케이션을 실행한다.
1. 디플로이먼트에 대한 정보를 보여준다.
```shell
kubectl get deployments hello-world
kubectl describe deployments hello-world
```
1. 레플리카셋 오브젝트에 대한 정보를 보여준다.
```shell
kubectl get replicasets
kubectl describe replicasets
```
1. 디플로이먼트를 노출하는 서비스 오브젝트를 생성한다.
```shell
kubectl expose deployment hello-world --type=NodePort --name=example-service
```
1. 서비스에 대한 정보를 보여준다.
```shell
kubectl describe services example-service
```
결과는 아래와 같다.
```shell
Name: example-service
Namespace: default
Labels: run=load-balancer-example
Annotations: <none>
Selector: run=load-balancer-example
Type: NodePort
IP: 10.32.0.16
Port: <unset> 8080/TCP
TargetPort: 8080/TCP
NodePort: <unset> 31496/TCP
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
Session Affinity: None
Events: <none>
```
서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어,
앞선 결과에서, 노드포트 값은 31496이다.
1. Hello World 애플리케이션이 실행 중인 파드를 나열한다.
```shell
kubectl get pods --selector="run=load-balancer-example" --output=wide
```
결과는 아래와 같다.
```shell
NAME READY STATUS ... IP NODE
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
```
1. Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용
IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에
따라 다르다. 예를 들어, Minikube를 사용하면, `kubectl cluster-info`를
실행하여 노드 주소를 알 수 있다. Google Compute Engine 인스턴스를
사용하면, `gcloud compute instances list` 명령어를
사용하여 노드들의 공용 주소를 알 수
있다.
1. 선택한 노드에서 노드 포트에 대해 TCP 통신을 허용하도록 방화벽 규칙을
생성하자. 예를 들어, 서비스의 노드포트 값이 31568인 경우,
31568 포트로 TCP 통신을 허용하도록 방화벽 규칙을 생성하자. 다른
클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다.
1. Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자.
```shell
curl http://<public-node-ip>:<node-port>
```
`<public-node-ip>`는 노드의 공용 IP 주소이고,
`<node-port>`는 서비스의 노드포트 값이다.
성공적인 요청에 대한 응답은 hello 메시지이다.
```shell
Hello Kubernetes!
```
## 서비스 설정 파일 사용하기
`kubectl expose`를 사용하는 대신,
[서비스 설정 파일](/ko/docs/concepts/services-networking/service/)을 사용해
서비스를 생성할 수 있다.
## {{% heading "cleanup" %}}
서비스를 삭제하기 위해 다음 명령어를 입력하자.
kubectl delete services example-service
디플로이먼트, 레플리카셋, Hello World 애플리케이션이 실행 중인 파드를
삭제하기 위해 다음 명령어를 입력하자.
kubectl delete deployment hello-world
## {{% heading "whatsnext" %}}
[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에
대해 더 알아본다.
@@ -258,4 +258,4 @@ kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보
## {{% heading "whatsnext" %}}
- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기
- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기
@@ -10,15 +10,11 @@ weight: 10
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
[쿠버네티스의 PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)에 익숙해야 한다.
<!-- steps -->
## 사용자 정의 인증서 사용 {#custom-certificates}
@@ -153,33 +149,29 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
### 서명자 설정
쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다.
[cert-manager][cert-manager-issuer] 와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.
[cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html)와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.
빌트인 서명자는 [`kube-controller-manager`][kcm] 의 일부이다.
빌트인 서명자는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 일부이다.
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file``--cluster-signing-key-file` 플래그를 전달해야 한다.
새 클러스터를 생성하는 경우, kubeadm [구성 파일][config]을 사용할 수 있다.
새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)을 사용할 수 있다.
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
```
[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html
[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
```yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
```
### 인증서 서명 요청(CSR) 생성
`kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
[cert-manager][cert-manager] 와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다.
[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.
```shell
@@ -195,7 +187,7 @@ sudo kubeadm alpha certs renew apiserver --use-api &
외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
```shell
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
@@ -227,20 +219,14 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다.
`kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.
CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
인증서를 발행할 때 [올바른 인증서 용도][cert-table]를 지정하는 것은 CA의 책임이다.
인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다.
* `openssl` 의 경우 [`openssl ca` command][openssl-ca] 명령으로 수행한다.
* `cfssl` 의 경우 [설정 파일에 용도][cfssl-usages]를 지정한다.
* `openssl` 의 경우
[`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다.
* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다.
선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다.
[cert-manager]: https://github.com/jetstack/cert-manager
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
[certs]: /ko/docs/setup/best-practices/certificates/
[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca
[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서
## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation}
Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
@@ -49,5 +49,4 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러
## {{% heading "whatsnext" %}}
클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -102,9 +102,6 @@ cilium-6rxbd 1/1 Running 0 1m
클러스터가 동작하면,
실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
재미있게 즐기고, 질문이 있다면
[실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다.
@@ -22,7 +22,4 @@ weight: 30
## {{% heading "whatsnext" %}}
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -38,4 +38,4 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman
## {{% heading "whatsnext" %}}
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
@@ -52,8 +52,4 @@ weave-net-pmw8w 2/2 Running 0 9d
## {{% heading "whatsnext" %}}
위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
@@ -88,4 +88,4 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
대해 배우기.
* [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기.
* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기.
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
@@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{<
glossary_tooltip text="kube-apiserver"
term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
`HugePageStorageMediumSize` [기능
게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.