Merge pull request #26964 from seokho-son/outdated-1.20-ko.6
[ko] Update outdated files in dev-1.20-ko.6 (p1)
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
98a1647ff6
|
|
@ -1,5 +1,8 @@
|
||||||
---
|
---
|
||||||
title: 클러스터 관리
|
title: 클러스터 관리
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
weight: 100
|
weight: 100
|
||||||
content_type: concept
|
content_type: concept
|
||||||
description: >
|
description: >
|
||||||
|
|
@ -11,6 +14,7 @@ no_list: true
|
||||||
클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
|
클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
|
||||||
핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
|
핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
|
||||||
|
|
||||||
|
|
||||||
<!-- body -->
|
<!-- body -->
|
||||||
## 클러스터 계획
|
## 클러스터 계획
|
||||||
|
|
||||||
|
|
@ -41,7 +45,7 @@ no_list: true
|
||||||
|
|
||||||
## 클러스터 보안
|
## 클러스터 보안
|
||||||
|
|
||||||
* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
|
* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
|
||||||
|
|
||||||
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
|
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -4,247 +4,6 @@ content_type: concept
|
||||||
weight: 20
|
weight: 20
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
<!-- overview -->
|
<!-- overview -->
|
||||||
|
|
||||||
클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl`
|
클러스터를 위한 인증서를 생성하기 위해서는, [인증서](/ko/docs/tasks/administer-cluster/certificates/)를 참고한다.
|
||||||
을 통해 인증서를 수동으로 생성할 수 있다.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<!-- body -->
|
|
||||||
|
|
||||||
### easyrsa
|
|
||||||
|
|
||||||
**easyrsa** 는 클러스터 인증서를 수동으로 생성할 수 있다.
|
|
||||||
|
|
||||||
1. easyrsa3의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다.
|
|
||||||
|
|
||||||
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
|
||||||
tar xzf easy-rsa.tar.gz
|
|
||||||
cd easy-rsa-master/easyrsa3
|
|
||||||
./easyrsa init-pki
|
|
||||||
1. 새로운 인증 기관(CA)을 생성한다. `--batch` 는 자동 모드를 설정한다.
|
|
||||||
`--req-cn` 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다.
|
|
||||||
|
|
||||||
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
|
||||||
1. 서버 인증서와 키를 생성한다.
|
|
||||||
`--subject-alt-name` 인수는 API 서버에 접근이 가능한 IP와 DNS
|
|
||||||
이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와
|
|
||||||
컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인수로
|
|
||||||
지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인수는 인증서가 만료되는
|
|
||||||
일 수를 설정하는데 사용된다.
|
|
||||||
또한, 아래 샘플은 기본 DNS 이름으로 `cluster.local` 을
|
|
||||||
사용한다고 가정한다.
|
|
||||||
|
|
||||||
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
|
||||||
"IP:${MASTER_CLUSTER_IP},"\
|
|
||||||
"DNS:kubernetes,"\
|
|
||||||
"DNS:kubernetes.default,"\
|
|
||||||
"DNS:kubernetes.default.svc,"\
|
|
||||||
"DNS:kubernetes.default.svc.cluster,"\
|
|
||||||
"DNS:kubernetes.default.svc.cluster.local" \
|
|
||||||
--days=10000 \
|
|
||||||
build-server-full server nopass
|
|
||||||
1. `pki/ca.crt`, `pki/issued/server.crt` 그리고 `pki/private/server.key` 를 디렉터리에 복사한다.
|
|
||||||
1. API 서버 시작 파라미터에 다음 파라미터를 채우고 추가한다.
|
|
||||||
|
|
||||||
--client-ca-file=/yourdirectory/ca.crt
|
|
||||||
--tls-cert-file=/yourdirectory/server.crt
|
|
||||||
--tls-private-key-file=/yourdirectory/server.key
|
|
||||||
|
|
||||||
### openssl
|
|
||||||
|
|
||||||
**openssl** 은 클러스터 인증서를 수동으로 생성할 수 있다.
|
|
||||||
|
|
||||||
1. ca.key를 2048bit로 생성한다.
|
|
||||||
|
|
||||||
openssl genrsa -out ca.key 2048
|
|
||||||
1. ca.key에 따라 ca.crt를 생성한다(인증서 유효 기간을 사용하려면 -days를 사용한다).
|
|
||||||
|
|
||||||
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
|
||||||
1. server.key를 2048bit로 생성한다.
|
|
||||||
|
|
||||||
openssl genrsa -out server.key 2048
|
|
||||||
1. 인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다.
|
|
||||||
파일에 저장하기 전에 꺾쇠 괄호(예: `<MASTER_IP>`)로
|
|
||||||
표시된 값을 실제 값으로 대체한다(예: `csr.conf`).
|
|
||||||
`MASTER_CLUSTER_IP` 의 값은 이전 하위 섹션에서
|
|
||||||
설명한 대로 API 서버의 서비스 클러스터 IP이다.
|
|
||||||
또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인
|
|
||||||
이름으로 사용하고 있다고 가정한다.
|
|
||||||
|
|
||||||
[ req ]
|
|
||||||
default_bits = 2048
|
|
||||||
prompt = no
|
|
||||||
default_md = sha256
|
|
||||||
req_extensions = req_ext
|
|
||||||
distinguished_name = dn
|
|
||||||
|
|
||||||
[ dn ]
|
|
||||||
C = <국가(country)>
|
|
||||||
ST = <도(state)>
|
|
||||||
L = <시(city)>
|
|
||||||
O = <조직(organization)>
|
|
||||||
OU = <조직 단위(organization unit)>
|
|
||||||
CN = <MASTER_IP>
|
|
||||||
|
|
||||||
[ req_ext ]
|
|
||||||
subjectAltName = @alt_names
|
|
||||||
|
|
||||||
[ alt_names ]
|
|
||||||
DNS.1 = kubernetes
|
|
||||||
DNS.2 = kubernetes.default
|
|
||||||
DNS.3 = kubernetes.default.svc
|
|
||||||
DNS.4 = kubernetes.default.svc.cluster
|
|
||||||
DNS.5 = kubernetes.default.svc.cluster.local
|
|
||||||
IP.1 = <MASTER_IP>
|
|
||||||
IP.2 = <MASTER_CLUSTER_IP>
|
|
||||||
|
|
||||||
[ v3_ext ]
|
|
||||||
authorityKeyIdentifier=keyid,issuer:always
|
|
||||||
basicConstraints=CA:FALSE
|
|
||||||
keyUsage=keyEncipherment,dataEncipherment
|
|
||||||
extendedKeyUsage=serverAuth,clientAuth
|
|
||||||
subjectAltName=@alt_names
|
|
||||||
1. 설정 파일을 기반으로 인증서 서명 요청을 생성한다.
|
|
||||||
|
|
||||||
openssl req -new -key server.key -out server.csr -config csr.conf
|
|
||||||
1. ca.key, ca.crt 그리고 server.csr을 사용해서 서버 인증서를 생성한다.
|
|
||||||
|
|
||||||
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
|
||||||
-CAcreateserial -out server.crt -days 10000 \
|
|
||||||
-extensions v3_ext -extfile csr.conf
|
|
||||||
1. 인증서를 본다.
|
|
||||||
|
|
||||||
openssl x509 -noout -text -in ./server.crt
|
|
||||||
|
|
||||||
마지막으로, API 서버 시작 파라미터에 동일한 파라미터를 추가한다.
|
|
||||||
|
|
||||||
### cfssl
|
|
||||||
|
|
||||||
**cfssl** 은 인증서 생성을 위한 또 다른 도구이다.
|
|
||||||
|
|
||||||
1. 아래에 표시된 대로 커맨드 라인 도구를 다운로드하여 압축을 풀고 준비한다.
|
|
||||||
사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플
|
|
||||||
명령을 조정해야 할 수도 있다.
|
|
||||||
|
|
||||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
|
|
||||||
chmod +x cfssl
|
|
||||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
|
|
||||||
chmod +x cfssljson
|
|
||||||
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
|
|
||||||
chmod +x cfssl-certinfo
|
|
||||||
1. 아티팩트(artifact)를 보유할 디렉터리를 생성하고 cfssl을 초기화한다.
|
|
||||||
|
|
||||||
mkdir cert
|
|
||||||
cd cert
|
|
||||||
../cfssl print-defaults config > config.json
|
|
||||||
../cfssl print-defaults csr > csr.json
|
|
||||||
1. CA 파일을 생성하기 위한 JSON 설정 파일을 `ca-config.json` 예시와 같이 생성한다.
|
|
||||||
|
|
||||||
{
|
|
||||||
"signing": {
|
|
||||||
"default": {
|
|
||||||
"expiry": "8760h"
|
|
||||||
},
|
|
||||||
"profiles": {
|
|
||||||
"kubernetes": {
|
|
||||||
"usages": [
|
|
||||||
"signing",
|
|
||||||
"key encipherment",
|
|
||||||
"server auth",
|
|
||||||
"client auth"
|
|
||||||
],
|
|
||||||
"expiry": "8760h"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
1. CA 인증서 서명 요청(CSR)을 위한 JSON 설정 파일을
|
|
||||||
`ca-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호로 표시된
|
|
||||||
값을 사용하려는 실제 값으로 변경한다.
|
|
||||||
|
|
||||||
{
|
|
||||||
"CN": "kubernetes",
|
|
||||||
"key": {
|
|
||||||
"algo": "rsa",
|
|
||||||
"size": 2048
|
|
||||||
},
|
|
||||||
"names":[{
|
|
||||||
"C": "<국가(country)>",
|
|
||||||
"ST": "<도(state)>",
|
|
||||||
"L": "<시(city)>",
|
|
||||||
"O": "<조직(organization)>",
|
|
||||||
"OU": "<조직 단위(organization unit)>"
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
1. CA 키(`ca-key.pem`)와 인증서(`ca.pem`)을 생성한다.
|
|
||||||
|
|
||||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
|
||||||
1. API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을
|
|
||||||
`server-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을
|
|
||||||
사용하려는 실제 값으로 변경한다. `MASTER_CLUSTER_IP` 는
|
|
||||||
이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다.
|
|
||||||
아래 샘플은 기본 DNS 도메인 이름으로 `cluster.local` 을
|
|
||||||
사용한다고 가정한다.
|
|
||||||
|
|
||||||
{
|
|
||||||
"CN": "kubernetes",
|
|
||||||
"hosts": [
|
|
||||||
"127.0.0.1",
|
|
||||||
"<MASTER_IP>",
|
|
||||||
"<MASTER_CLUSTER_IP>",
|
|
||||||
"kubernetes",
|
|
||||||
"kubernetes.default",
|
|
||||||
"kubernetes.default.svc",
|
|
||||||
"kubernetes.default.svc.cluster",
|
|
||||||
"kubernetes.default.svc.cluster.local"
|
|
||||||
],
|
|
||||||
"key": {
|
|
||||||
"algo": "rsa",
|
|
||||||
"size": 2048
|
|
||||||
},
|
|
||||||
"names": [{
|
|
||||||
"C": "<국가(country)>",
|
|
||||||
"ST": "<도(state)>",
|
|
||||||
"L": "<시(city)>",
|
|
||||||
"O": "<조직(organization)>",
|
|
||||||
"OU": "<조직 단위(organization unit)>"
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
1. API 서버 키와 인증서를 생성하면, 기본적으로
|
|
||||||
`server-key.pem` 과 `server.pem` 파일에 각각 저장된다.
|
|
||||||
|
|
||||||
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
|
||||||
--config=ca-config.json -profile=kubernetes \
|
|
||||||
server-csr.json | ../cfssljson -bare server
|
|
||||||
|
|
||||||
|
|
||||||
## 자체 서명된 CA 인증서의 배포
|
|
||||||
|
|
||||||
클라이언트 노드는 자체 서명된 CA 인증서를 유효한 것으로 인식하지 않을 수 있다.
|
|
||||||
비-프로덕션 디플로이먼트 또는 회사 방화벽 뒤에서 실행되는
|
|
||||||
디플로이먼트의 경우, 자체 서명된 CA 인증서를 모든 클라이언트에
|
|
||||||
배포하고 유효한 인증서의 로컬 목록을 새로 고칠 수 있다.
|
|
||||||
|
|
||||||
각 클라이언트에서, 다음 작업을 수행한다.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
|
|
||||||
sudo update-ca-certificates
|
|
||||||
```
|
|
||||||
|
|
||||||
```
|
|
||||||
Updating certificates in /etc/ssl/certs...
|
|
||||||
1 added, 0 removed; done.
|
|
||||||
Running hooks in /etc/ca-certificates/update.d....
|
|
||||||
done.
|
|
||||||
```
|
|
||||||
|
|
||||||
## 인증서 API
|
|
||||||
|
|
||||||
`certificates.k8s.io` API를 사용해서
|
|
||||||
[여기](/docs/tasks/tls/managing-tls-in-a-cluster)에
|
|
||||||
설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다.
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,7 @@
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
title: 컨테이너 환경 변수
|
title: 컨테이너 환경 변수
|
||||||
content_type: concept
|
content_type: concept
|
||||||
weight: 20
|
weight: 20
|
||||||
|
|
@ -38,6 +41,7 @@ Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
||||||
|
|
||||||
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
||||||
있다.
|
있다.
|
||||||
|
이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
|
||||||
이러한 환경 변수는 Docker 링크 구문과 일치한다.
|
이러한 환경 변수는 Docker 링크 구문과 일치한다.
|
||||||
|
|
||||||
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
||||||
|
|
@ -58,5 +62,3 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
|
||||||
* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
|
* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
|
||||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||||
실제 경험 얻기.
|
실제 경험 얻기.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,9 @@
|
||||||
---
|
---
|
||||||
title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
|
title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
content_type: concept
|
content_type: concept
|
||||||
weight: 10
|
weight: 10
|
||||||
---
|
---
|
||||||
|
|
@ -25,8 +29,6 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮
|
||||||
kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
|
kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
|
||||||
|
|
||||||
extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
|
extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
|
||||||
`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
|
|
||||||
제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.
|
|
||||||
|
|
||||||
## {{% heading "whatsnext" %}}
|
## {{% heading "whatsnext" %}}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -124,5 +124,5 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
||||||
사용하여 직접 구현하기
|
사용하여 직접 구현하기
|
||||||
* [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
|
* [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
|
||||||
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
|
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
|
||||||
* 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기
|
* 오퍼레이터 패턴을 소개한 [CoreOS 원본 글](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) 읽기 (이 링크는 원본 글에 대한 보관 버전임)
|
||||||
* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
|
* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
|
||||||
|
|
|
||||||
|
|
@ -52,6 +52,11 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
|
||||||
|
|
||||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
||||||
|
|
||||||
|
유효한 레이블 값은 다음과 같다.
|
||||||
|
* 63 자 이하 여야 하고(공백이면 안 됨),
|
||||||
|
* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
|
||||||
|
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
|
||||||
|
|
||||||
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
||||||
|
|
||||||
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
|
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
|
||||||
|
|
|
||||||
|
|
@ -58,7 +58,7 @@ weight: 20
|
||||||
## 리소스 쿼터 활성화
|
## 리소스 쿼터 활성화
|
||||||
|
|
||||||
많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
|
많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
|
||||||
API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
|
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로
|
||||||
`ResourceQuota`가 있는 경우 활성화된다.
|
`ResourceQuota`가 있는 경우 활성화된다.
|
||||||
|
|
||||||
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
|
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,14 @@
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
title: 서비스 및 파드용 DNS
|
title: 서비스 및 파드용 DNS
|
||||||
content_type: concept
|
content_type: concept
|
||||||
weight: 20
|
weight: 20
|
||||||
---
|
---
|
||||||
<!-- overview -->
|
<!-- overview -->
|
||||||
이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다.
|
쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
|
||||||
|
일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.
|
||||||
|
|
||||||
<!-- body -->
|
<!-- body -->
|
||||||
|
|
||||||
|
|
@ -15,23 +18,51 @@ weight: 20
|
||||||
개별 컨테이너들이 DNS 네임을 해석할 때
|
개별 컨테이너들이 DNS 네임을 해석할 때
|
||||||
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
||||||
|
|
||||||
### DNS 네임이 할당되는 것들
|
|
||||||
|
|
||||||
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
||||||
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
||||||
클러스터의 기본 도메인을 포함한다.
|
클러스터의 기본 도메인을 포함한다.
|
||||||
이 예시는 다음과 같다.
|
|
||||||
|
|
||||||
쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는
|
### 서비스의 네임스페이스
|
||||||
단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다.
|
|
||||||
네임스페이스 `quux`에서 실행 중인 파드는
|
|
||||||
`foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다.
|
|
||||||
|
|
||||||
다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
|
DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다른 결과를 반환할 수
|
||||||
이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며
|
있다. 네임스페이스를 지정하지 않은 DNS 쿼리는 파드의 네임스페이스에
|
||||||
경고 없이 변경될 수 있다.
|
국한된다. DNS 쿼리에 네임스페이스를 명시하여 다른 네임스페이스에 있는 서비스에 접속한다.
|
||||||
최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다.
|
|
||||||
[쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
예를 들어, `test` 네임스페이스에 있는 파드를 생각해보자. `data` 서비스는
|
||||||
|
`prod` 네임스페이스에 있다.
|
||||||
|
|
||||||
|
이 경우, `data` 에 대한 쿼리는 파드의 `test` 네임스페이스를 사용하기 때문에 결과를 반환하지 않을 것이다.
|
||||||
|
|
||||||
|
`data.prod` 로 쿼리하면 의도한 결과를 반환할 것이다. 왜냐하면
|
||||||
|
네임스페이스가 명시되어 있기 때문이다.
|
||||||
|
|
||||||
|
DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은
|
||||||
|
각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는
|
||||||
|
`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은
|
||||||
|
쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
|
||||||
|
[`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다.
|
||||||
|
|
||||||
|
```
|
||||||
|
nameserver 10.32.0.10
|
||||||
|
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
|
||||||
|
options ndots:5
|
||||||
|
```
|
||||||
|
|
||||||
|
요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는
|
||||||
|
`data.prod.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
|
||||||
|
|
||||||
|
### DNS 레코드
|
||||||
|
|
||||||
|
어떤 오브젝트가 DNS 레코드를 가지는가?
|
||||||
|
|
||||||
|
1. 서비스
|
||||||
|
2. 파드
|
||||||
|
|
||||||
|
다음 섹션은 지원되는 DNS 레코드의 종류 및 레이아웃에 대한 상세
|
||||||
|
내용이다. 혹시 동작시킬 필요가 있는 다른 레이아웃, 네임, 또는 쿼리는
|
||||||
|
구현 세부 사항으로 간주되며 경고 없이 변경될 수 있다.
|
||||||
|
최신 명세 확인을 위해서는,
|
||||||
|
[쿠버네티스 DNS-기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 본다.
|
||||||
|
|
||||||
## 서비스
|
## 서비스
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,250 @@
|
||||||
|
---
|
||||||
|
title: 인증서
|
||||||
|
content_type: task
|
||||||
|
weight: 20
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
<!-- overview -->
|
||||||
|
|
||||||
|
클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl`
|
||||||
|
을 통해 인증서를 수동으로 생성할 수 있다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<!-- body -->
|
||||||
|
|
||||||
|
### easyrsa
|
||||||
|
|
||||||
|
**easyrsa** 는 클러스터 인증서를 수동으로 생성할 수 있다.
|
||||||
|
|
||||||
|
1. easyrsa3의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다.
|
||||||
|
|
||||||
|
curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
|
||||||
|
tar xzf easy-rsa.tar.gz
|
||||||
|
cd easy-rsa-master/easyrsa3
|
||||||
|
./easyrsa init-pki
|
||||||
|
1. 새로운 인증 기관(CA)을 생성한다. `--batch` 는 자동 모드를 설정한다.
|
||||||
|
`--req-cn` 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다.
|
||||||
|
|
||||||
|
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
|
||||||
|
1. 서버 인증서와 키를 생성한다.
|
||||||
|
`--subject-alt-name` 인수는 API 서버에 접근이 가능한 IP와 DNS
|
||||||
|
이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와
|
||||||
|
컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인수로
|
||||||
|
지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인수는 인증서가 만료되는
|
||||||
|
일 수를 설정하는데 사용된다.
|
||||||
|
또한, 아래 샘플은 기본 DNS 이름으로 `cluster.local` 을
|
||||||
|
사용한다고 가정한다.
|
||||||
|
|
||||||
|
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
|
||||||
|
"IP:${MASTER_CLUSTER_IP},"\
|
||||||
|
"DNS:kubernetes,"\
|
||||||
|
"DNS:kubernetes.default,"\
|
||||||
|
"DNS:kubernetes.default.svc,"\
|
||||||
|
"DNS:kubernetes.default.svc.cluster,"\
|
||||||
|
"DNS:kubernetes.default.svc.cluster.local" \
|
||||||
|
--days=10000 \
|
||||||
|
build-server-full server nopass
|
||||||
|
1. `pki/ca.crt`, `pki/issued/server.crt` 그리고 `pki/private/server.key` 를 디렉터리에 복사한다.
|
||||||
|
1. API 서버 시작 파라미터에 다음 파라미터를 채우고 추가한다.
|
||||||
|
|
||||||
|
--client-ca-file=/yourdirectory/ca.crt
|
||||||
|
--tls-cert-file=/yourdirectory/server.crt
|
||||||
|
--tls-private-key-file=/yourdirectory/server.key
|
||||||
|
|
||||||
|
### openssl
|
||||||
|
|
||||||
|
**openssl** 은 클러스터 인증서를 수동으로 생성할 수 있다.
|
||||||
|
|
||||||
|
1. ca.key를 2048bit로 생성한다.
|
||||||
|
|
||||||
|
openssl genrsa -out ca.key 2048
|
||||||
|
1. ca.key에 따라 ca.crt를 생성한다(인증서 유효 기간을 사용하려면 -days를 사용한다).
|
||||||
|
|
||||||
|
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
|
||||||
|
1. server.key를 2048bit로 생성한다.
|
||||||
|
|
||||||
|
openssl genrsa -out server.key 2048
|
||||||
|
1. 인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다.
|
||||||
|
파일에 저장하기 전에 꺾쇠 괄호(예: `<MASTER_IP>`)로
|
||||||
|
표시된 값을 실제 값으로 대체한다(예: `csr.conf`).
|
||||||
|
`MASTER_CLUSTER_IP` 의 값은 이전 하위 섹션에서
|
||||||
|
설명한 대로 API 서버의 서비스 클러스터 IP이다.
|
||||||
|
또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인
|
||||||
|
이름으로 사용하고 있다고 가정한다.
|
||||||
|
|
||||||
|
[ req ]
|
||||||
|
default_bits = 2048
|
||||||
|
prompt = no
|
||||||
|
default_md = sha256
|
||||||
|
req_extensions = req_ext
|
||||||
|
distinguished_name = dn
|
||||||
|
|
||||||
|
[ dn ]
|
||||||
|
C = <국가(country)>
|
||||||
|
ST = <도(state)>
|
||||||
|
L = <시(city)>
|
||||||
|
O = <조직(organization)>
|
||||||
|
OU = <조직 단위(organization unit)>
|
||||||
|
CN = <MASTER_IP>
|
||||||
|
|
||||||
|
[ req_ext ]
|
||||||
|
subjectAltName = @alt_names
|
||||||
|
|
||||||
|
[ alt_names ]
|
||||||
|
DNS.1 = kubernetes
|
||||||
|
DNS.2 = kubernetes.default
|
||||||
|
DNS.3 = kubernetes.default.svc
|
||||||
|
DNS.4 = kubernetes.default.svc.cluster
|
||||||
|
DNS.5 = kubernetes.default.svc.cluster.local
|
||||||
|
IP.1 = <MASTER_IP>
|
||||||
|
IP.2 = <MASTER_CLUSTER_IP>
|
||||||
|
|
||||||
|
[ v3_ext ]
|
||||||
|
authorityKeyIdentifier=keyid,issuer:always
|
||||||
|
basicConstraints=CA:FALSE
|
||||||
|
keyUsage=keyEncipherment,dataEncipherment
|
||||||
|
extendedKeyUsage=serverAuth,clientAuth
|
||||||
|
subjectAltName=@alt_names
|
||||||
|
1. 설정 파일을 기반으로 인증서 서명 요청을 생성한다.
|
||||||
|
|
||||||
|
openssl req -new -key server.key -out server.csr -config csr.conf
|
||||||
|
1. ca.key, ca.crt 그리고 server.csr을 사용해서 서버 인증서를 생성한다.
|
||||||
|
|
||||||
|
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
|
||||||
|
-CAcreateserial -out server.crt -days 10000 \
|
||||||
|
-extensions v3_ext -extfile csr.conf
|
||||||
|
1. 인증서를 본다.
|
||||||
|
|
||||||
|
openssl x509 -noout -text -in ./server.crt
|
||||||
|
|
||||||
|
마지막으로, API 서버 시작 파라미터에 동일한 파라미터를 추가한다.
|
||||||
|
|
||||||
|
### cfssl
|
||||||
|
|
||||||
|
**cfssl** 은 인증서 생성을 위한 또 다른 도구이다.
|
||||||
|
|
||||||
|
1. 아래에 표시된 대로 커맨드 라인 도구를 다운로드하여 압축을 풀고 준비한다.
|
||||||
|
사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플
|
||||||
|
명령을 조정해야 할 수도 있다.
|
||||||
|
|
||||||
|
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
|
||||||
|
chmod +x cfssl
|
||||||
|
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
|
||||||
|
chmod +x cfssljson
|
||||||
|
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
|
||||||
|
chmod +x cfssl-certinfo
|
||||||
|
1. 아티팩트(artifact)를 보유할 디렉터리를 생성하고 cfssl을 초기화한다.
|
||||||
|
|
||||||
|
mkdir cert
|
||||||
|
cd cert
|
||||||
|
../cfssl print-defaults config > config.json
|
||||||
|
../cfssl print-defaults csr > csr.json
|
||||||
|
1. CA 파일을 생성하기 위한 JSON 설정 파일을 `ca-config.json` 예시와 같이 생성한다.
|
||||||
|
|
||||||
|
{
|
||||||
|
"signing": {
|
||||||
|
"default": {
|
||||||
|
"expiry": "8760h"
|
||||||
|
},
|
||||||
|
"profiles": {
|
||||||
|
"kubernetes": {
|
||||||
|
"usages": [
|
||||||
|
"signing",
|
||||||
|
"key encipherment",
|
||||||
|
"server auth",
|
||||||
|
"client auth"
|
||||||
|
],
|
||||||
|
"expiry": "8760h"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
1. CA 인증서 서명 요청(CSR)을 위한 JSON 설정 파일을
|
||||||
|
`ca-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호로 표시된
|
||||||
|
값을 사용하려는 실제 값으로 변경한다.
|
||||||
|
|
||||||
|
{
|
||||||
|
"CN": "kubernetes",
|
||||||
|
"key": {
|
||||||
|
"algo": "rsa",
|
||||||
|
"size": 2048
|
||||||
|
},
|
||||||
|
"names":[{
|
||||||
|
"C": "<국가(country)>",
|
||||||
|
"ST": "<도(state)>",
|
||||||
|
"L": "<시(city)>",
|
||||||
|
"O": "<조직(organization)>",
|
||||||
|
"OU": "<조직 단위(organization unit)>"
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
1. CA 키(`ca-key.pem`)와 인증서(`ca.pem`)을 생성한다.
|
||||||
|
|
||||||
|
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||||
|
1. API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을
|
||||||
|
`server-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을
|
||||||
|
사용하려는 실제 값으로 변경한다. `MASTER_CLUSTER_IP` 는
|
||||||
|
이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다.
|
||||||
|
아래 샘플은 기본 DNS 도메인 이름으로 `cluster.local` 을
|
||||||
|
사용한다고 가정한다.
|
||||||
|
|
||||||
|
{
|
||||||
|
"CN": "kubernetes",
|
||||||
|
"hosts": [
|
||||||
|
"127.0.0.1",
|
||||||
|
"<MASTER_IP>",
|
||||||
|
"<MASTER_CLUSTER_IP>",
|
||||||
|
"kubernetes",
|
||||||
|
"kubernetes.default",
|
||||||
|
"kubernetes.default.svc",
|
||||||
|
"kubernetes.default.svc.cluster",
|
||||||
|
"kubernetes.default.svc.cluster.local"
|
||||||
|
],
|
||||||
|
"key": {
|
||||||
|
"algo": "rsa",
|
||||||
|
"size": 2048
|
||||||
|
},
|
||||||
|
"names": [{
|
||||||
|
"C": "<국가(country)>",
|
||||||
|
"ST": "<도(state)>",
|
||||||
|
"L": "<시(city)>",
|
||||||
|
"O": "<조직(organization)>",
|
||||||
|
"OU": "<조직 단위(organization unit)>"
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
1. API 서버 키와 인증서를 생성하면, 기본적으로
|
||||||
|
`server-key.pem` 과 `server.pem` 파일에 각각 저장된다.
|
||||||
|
|
||||||
|
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
|
||||||
|
--config=ca-config.json -profile=kubernetes \
|
||||||
|
server-csr.json | ../cfssljson -bare server
|
||||||
|
|
||||||
|
|
||||||
|
## 자체 서명된 CA 인증서의 배포
|
||||||
|
|
||||||
|
클라이언트 노드는 자체 서명된 CA 인증서를 유효한 것으로 인식하지 않을 수 있다.
|
||||||
|
비-프로덕션 디플로이먼트 또는 회사 방화벽 뒤에서 실행되는
|
||||||
|
디플로이먼트의 경우, 자체 서명된 CA 인증서를 모든 클라이언트에
|
||||||
|
배포하고 유효한 인증서의 로컬 목록을 새로 고칠 수 있다.
|
||||||
|
|
||||||
|
각 클라이언트에서, 다음 작업을 수행한다.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
|
||||||
|
sudo update-ca-certificates
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Updating certificates in /etc/ssl/certs...
|
||||||
|
1 added, 0 removed; done.
|
||||||
|
Running hooks in /etc/ca-certificates/update.d....
|
||||||
|
done.
|
||||||
|
```
|
||||||
|
|
||||||
|
## 인증서 API
|
||||||
|
|
||||||
|
`certificates.k8s.io` API를 사용해서
|
||||||
|
[여기](/docs/tasks/tls/managing-tls-in-a-cluster)에
|
||||||
|
설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다.
|
||||||
Loading…
Reference in New Issue