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:
@@ -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)을 본다.
|
||||
|
||||
+158
@@ -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 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다.
|
||||
|
||||
+1
-2
@@ -49,5 +49,4 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
|
||||
[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
+1
-4
@@ -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/)을 이용하여 연락한다.
|
||||
|
||||
|
||||
|
||||
|
||||
+1
-4
@@ -22,7 +22,4 @@ weight: 30
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
|
||||
|
||||
큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
|
||||
|
||||
+1
-1
@@ -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/)를 따라 할 수 있다.
|
||||
|
||||
+1
-5
@@ -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/)를 사용하여 활성화할 수 있다.
|
||||
|
||||
Reference in New Issue
Block a user