Merge pull request #27133 from kubernetes/dev-1.20-ko.6
[ko] Sixth Korean l10n work for release-1.20pull/27143/head
Kubernetes Prow Robot
GitHub
commit
8c837edc4b
|
|
@ -102,7 +102,7 @@ weight: 30
|
|||
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
|
||||
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
|
||||
[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
|
||||
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및
|
||||
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및
|
||||
기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
|
||||
|
||||
## 의도한 상태와 현재 상태 {#desired-vs-current}
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
|
|||
정상적인지 확인한다.
|
||||
|
||||
상태 확인을 중지하려면 사용자 또는 {{< glossary_tooltip term_id="controller" text="컨트롤러">}}에서
|
||||
노드 오브젝트를 명시적으로 삭제해야한다.
|
||||
노드 오브젝트를 명시적으로 삭제해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
노드 오브젝트의 이름은 유효한
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: 클러스터 관리
|
||||
|
||||
|
||||
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
|
|
@ -11,6 +14,7 @@ no_list: true
|
|||
클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다.
|
||||
핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다.
|
||||
|
||||
|
||||
<!-- 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으로 관리하는 컨테이너에 대한 환경을 설명한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,247 +4,6 @@ content_type: concept
|
|||
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 인증서를 프로비전 할 수 있다.
|
||||
클러스터를 위한 인증서를 생성하기 위해서는, [인증서](/ko/docs/tasks/administer-cluster/certificates/)를 참고한다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 컨테이너 환경 변수
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -24,11 +27,11 @@ weight: 20
|
|||
### 컨테이너 정보
|
||||
|
||||
컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다.
|
||||
그것은 `hostname` 커맨드 또는 libc의
|
||||
[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html)
|
||||
그것은 `hostname` 커맨드 또는 libc의
|
||||
[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html)
|
||||
함수 호출을 통해서 구할 수 있다.
|
||||
|
||||
파드 이름과 네임스페이스는
|
||||
파드 이름과 네임스페이스는
|
||||
[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
|
||||
|
||||
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
||||
|
|
@ -36,11 +39,12 @@ Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
|||
|
||||
### 클러스터 정보
|
||||
|
||||
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
||||
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
||||
있다.
|
||||
이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
|
||||
이러한 환경 변수는 Docker 링크 구문과 일치한다.
|
||||
|
||||
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
||||
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
||||
다음의 형태로 변수가 정의된다.
|
||||
|
||||
```shell
|
||||
|
|
@ -58,5 +62,3 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
|
|||
* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
|
||||
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
실제 경험 얻기.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
|
||||
|
||||
|
||||
|
||||
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
|
@ -25,8 +29,6 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮
|
|||
kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다.
|
||||
|
||||
extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다.
|
||||
`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
|
||||
제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -124,5 +124,5 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
|
|||
사용하여 직접 구현하기
|
||||
* [오퍼레이터 프레임워크](https://operatorframework.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) 읽기
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ sitemap:
|
|||
|
||||
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
|
||||
|
||||
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
|
||||
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
|
||||
|
||||
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -52,6 +52,11 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
|
|||
|
||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
||||
|
||||
유효한 레이블 값은 다음과 같다.
|
||||
* 63 자 이하 여야 하고(공백이면 안 됨),
|
||||
* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
|
||||
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
|
||||
|
||||
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
||||
|
||||
다음의 예시는 파드에 `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`가 있는 경우 활성화된다.
|
||||
|
||||
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
|
||||
|
|
|
|||
|
|
@ -1,11 +1,14 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 서비스 및 파드용 DNS
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!-- overview -->
|
||||
이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다.
|
||||
|
||||
쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
|
||||
일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -15,23 +18,51 @@ weight: 20
|
|||
개별 컨테이너들이 DNS 네임을 해석할 때
|
||||
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
||||
|
||||
### DNS 네임이 할당되는 것들
|
||||
|
||||
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
||||
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
||||
클러스터의 기본 도메인을 포함한다.
|
||||
이 예시는 다음과 같다.
|
||||
|
||||
쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는
|
||||
단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다.
|
||||
네임스페이스 `quux`에서 실행 중인 파드는
|
||||
`foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다.
|
||||
### 서비스의 네임스페이스
|
||||
|
||||
다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
|
||||
이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며
|
||||
경고 없이 변경될 수 있다.
|
||||
최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다.
|
||||
[쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
||||
DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다른 결과를 반환할 수
|
||||
있다. 네임스페이스를 지정하지 않은 DNS 쿼리는 파드의 네임스페이스에
|
||||
국한된다. DNS 쿼리에 네임스페이스를 명시하여 다른 네임스페이스에 있는 서비스에 접속한다.
|
||||
|
||||
예를 들어, `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)를 본다.
|
||||
|
||||
## 서비스
|
||||
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ weight: 40
|
|||
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
|
||||
|
||||
{{< note >}}
|
||||
인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다.
|
||||
인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -311,7 +311,7 @@ IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을
|
|||
|
||||
{{< note >}}
|
||||
IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
|
||||
사용 가능하도록 해야한다.
|
||||
사용 가능하도록 해야 한다.
|
||||
|
||||
kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을
|
||||
사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는
|
||||
|
|
@ -1120,7 +1120,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
|
|||
않아도 된다. 그것은 격리 실패이다.
|
||||
|
||||
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
|
||||
서비스가 충돌하지 않도록 해야한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
|
||||
서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
|
||||
할당하여 이를 수행한다.
|
||||
|
||||
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ parameters:
|
|||
### 드라이버
|
||||
|
||||
볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
|
||||
결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다.
|
||||
결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야 한다.
|
||||
|
||||
### 삭제정책(DeletionPolicy)
|
||||
|
||||
|
|
|
|||
|
|
@ -1332,7 +1332,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
|
|||
* `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume`
|
||||
그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는
|
||||
민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는
|
||||
선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
|
||||
선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
|
||||
둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다.
|
||||
* `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해
|
||||
CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿
|
||||
|
|
|
|||
|
|
@ -341,7 +341,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
|
|||
API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다.
|
||||
* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트해야 한다.
|
||||
그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가
|
||||
이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며,
|
||||
새로운 레플리카셋을 생성하게 된다.
|
||||
|
|
@ -1060,7 +1060,7 @@ echo $?
|
|||
이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
|
||||
|
||||
파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
|
||||
레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
|
||||
레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
|
||||
|
||||
[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고,
|
||||
명시되지 않으면 기본값이 된다.
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ kubectl 명령에서 숏컷으로 사용된다.
|
|||
|
||||
{{< codenew file="controllers/replication.yaml" >}}
|
||||
|
||||
예제 파일을 다운로드 한 후 다음 명령을 실행하여 예제 작업을 실행하라.
|
||||
예제 파일을 다운로드한 후 다음 명령을 실행하여 예제 작업을 실행하라.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ spec:
|
|||
|
||||
## 파드 셀렉터
|
||||
|
||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||
|
||||
## 파드 신원
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
|
|||
파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
|
||||
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
|
||||
파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
|
||||
이것은 반드시 수동으로 해야한다.
|
||||
이것은 반드시 수동으로 해야 한다.
|
||||
|
||||
### 파드 이름 레이블
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ PDB는 자발적 중단으로
|
|||
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
|
||||
|
||||
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
|
||||
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
|
||||
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)로
|
||||
불리는 PodDisruptionBudget을 준수하는 도구를 이용해야 한다.
|
||||
|
||||
예를 들어, `kubectl drain` 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수
|
||||
|
|
|
|||
|
|
@ -38,8 +38,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가
|
|||
타임아웃 기간 후에 [삭제되도록 스케줄된다](#pod-garbage-collection).
|
||||
|
||||
파드는 자체적으로 자가 치유되지 않는다. 파드가
|
||||
{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 실패하거나,
|
||||
스케줄 작업 자체가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
|
||||
{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 해당 노드가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
|
||||
리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는
|
||||
{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라
|
||||
부르는 하이-레벨 추상화를 사용하여
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.13 | - |
|
||||
| `VolumeSubpath` | `true` | GA | 1.10 | - |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: 퍼시스턴트 볼륨 클레임(Persistent Volume Claim)
|
||||
id: persistent-volume-claim
|
||||
date: 2018-04-12
|
||||
full_link: /ko/docs/concepts/storage/persistent-volumes/
|
||||
short_description: >
|
||||
컨테이너의 볼륨으로 마운트될 수 있도록 퍼시스턴트볼륨(PersistentVolume)에 정의된 스토리지 리소스를 요청한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 볼륨으로 마운트될 수 있도록 {{< glossary_tooltip text="퍼시스턴트볼륨(PersistentVolume)" term_id="persistent-volume" >}}에 정의된 스토리지 리소스를 요청한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
스토리지의 양, 스토리지에 엑세스하는 방법(읽기 전용, 읽기 그리고/또는 쓰기) 및 재확보(보존, 재활용 혹은 삭제) 방법을 지정한다. 스토리지 자체에 관한 내용은 퍼시스턴트볼륨 오브젝트에 설명되어 있다.
|
||||
|
|
@ -293,12 +293,12 @@ kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{pr
|
|||
## 실행 중인 파드와 상호 작용
|
||||
|
||||
```bash
|
||||
kubectl logs my-pod # 파드 로그(stdout) 덤프
|
||||
kubectl logs my-pod # 파드 로그 덤프 (stdout)
|
||||
kubectl logs -l name=myLabel # name이 myLabel인 파드 로그 덤프 (stdout)
|
||||
kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout) 덤프
|
||||
kubectl logs my-pod -c my-container # 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
|
||||
kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout)
|
||||
kubectl logs my-pod -c my-container # 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
|
||||
kubectl logs -l name=myLabel -c my-container # name이 myLabel인 파드 로그 덤프 (stdout)
|
||||
kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
|
||||
kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
|
||||
kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout)
|
||||
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
|
||||
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
|
||||
|
|
@ -317,6 +317,18 @@ kubectl top pod POD_NAME --containers # 특정 파드와 해당
|
|||
kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
|
||||
```
|
||||
|
||||
## 디플로이먼트, 서비스와 상호 작용
|
||||
```bash
|
||||
kubectl logs deploy/my-deployment # 디플로이먼트에 대한 파드 로그 덤프 (단일-컨테이너 경우)
|
||||
kubectl logs deploy/my-deployment -c my-container # 디플로이먼트에 대한 파드 로그 덤프 (멀티-컨테이너 경우)
|
||||
|
||||
kubectl port-forward svc/my-service 5000 # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 동일한(5000번) 포트로 전달
|
||||
kubectl port-forward svc/my-service 5000:my-service-port # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 <my-service-port> 라는 이름을 가진 포트로 전달
|
||||
|
||||
kubectl port-forward deploy/my-deployment 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, <my-deployment> 에 의해 생성된 파드의 6000번 포트로 전달
|
||||
kubectl exec deploy/my-deployment -- ls # <my-deployment> 에 의해 생성된 첫번째 파드의 첫번째 컨테이너에 명령어 실행 (단일- 또는 다중-컨테이너 경우)
|
||||
```
|
||||
|
||||
## 노드, 클러스터와 상호 작용
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ content_type: concept
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.
|
||||
당신은 쿠버네티스 커맨드 라인 도구인 `kubectl`을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 `kubectl`을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 `kubectl`과 같은 명령어를 설명한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
|
|
|||
|
|
@ -65,12 +65,13 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
|
|||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
|
||||
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
|
||||
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
|
||||
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
|
||||
| Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
|
||||
| Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
|
||||
| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
|
||||
| Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) |
|
||||
| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
|
||||
| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) |
|
||||
|
|
|
|||
|
|
@ -155,5 +155,5 @@ KUBECONFIG=<filename> kubectl config use-context default-system
|
|||
|-------------------------|-------------------------|-----------------------------------------------------------------------|
|
||||
| admin.conf | kubectl | 클러스터 관리자를 설정한다. |
|
||||
| kubelet.conf | kubelet | 클러스터 각 노드를 위해 필요하다. |
|
||||
| controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
|
||||
| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. |
|
||||
| controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야 한다. |
|
||||
| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야 한다. |
|
||||
|
|
|
|||
|
|
@ -219,11 +219,16 @@ sudo systemctl restart containerd
|
|||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
<br />
|
||||
Powershell 세션을 띄우고, `$Version` 환경 변수를 원하는 버전으로 설정(예: `$Version=1.4.3`)한 뒤, 다음 명령어를 실행한다.
|
||||
<br />
|
||||
|
||||
```powershell
|
||||
# (containerd 설치)
|
||||
# containerd 다운로드
|
||||
cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz
|
||||
cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
```powershell
|
||||
|
|
@ -236,7 +241,9 @@ cd $Env:ProgramFiles\containerd\
|
|||
# - sandbox_image (쿠버네티스 pause 이미지)
|
||||
# - cni bin_dir 및 conf_dir locations
|
||||
Get-Content config.toml
|
||||
```
|
||||
|
||||
# (선택 사항이지만, 강력히 권장됨) containerd를 Windows Defender 검사 예외에 추가
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ```
|
||||
|
||||
```powershell
|
||||
# containerd 시작
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ kops는 자동화된 프로비저닝 시스템인데,
|
|||
|
||||
#### 설치
|
||||
|
||||
[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스 코드로부터 빌드하는 것도 역시 편리하다).
|
||||
[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드한다(소스 코드로부터 빌드하는 것도 역시 편리하다).
|
||||
|
||||
{{< tabs name="kops_installation" >}}
|
||||
{{% tab name="macOS" %}}
|
||||
|
|
|
|||
|
|
@ -18,14 +18,7 @@ card:
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* 다음 중 하나를 실행하는 하나 이상의 머신이 필요하다.
|
||||
- Ubuntu 16.04+
|
||||
- Debian 9+
|
||||
- CentOS 7+
|
||||
- Red Hat Enterprise Linux (RHEL) 7+
|
||||
- Fedora 25+
|
||||
- HypriotOS v1.0.1+
|
||||
- Flatcar Container Linux (2512.3.0으로 테스트됨)
|
||||
* 호환되는 리눅스 머신. 쿠버네티스 프로젝트는 데비안 기반 배포판, 레드햇 기반 배포판, 그리고 패키지 매니저를 사용하지 않는 경우에 대한 일반적인 가이드를 제공한다.
|
||||
* 2 GB 이상의 램을 장착한 머신. (이 보다 작으면 사용자의 앱을 위한 공간이 거의 남지 않음)
|
||||
* 2 이상의 CPU.
|
||||
* 클러스터의 모든 머신에 걸친 전체 네트워크 연결. (공용 또는 사설 네트워크면 괜찮음)
|
||||
|
|
@ -121,7 +114,7 @@ etcd 포트가 컨트롤 플레인 노드에 포함되어 있지만, 외부 또
|
|||
{{< table caption = "컨테이너 런타임과 소켓 경로" >}}
|
||||
| 런타임 | 유닉스 도메인 소켓 경로 |
|
||||
|------------|-----------------------------------|
|
||||
| 도커 | `/var/run/docker.sock` |
|
||||
| 도커 | `/var/run/dockershim.sock` |
|
||||
| containerd | `/run/containerd/containerd.sock` |
|
||||
| CRI-O | `/var/run/crio/crio.sock` |
|
||||
{{< /table >}}
|
||||
|
|
@ -180,7 +173,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으
|
|||
* Kubeadm 관련 [버전 차이 정책](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
|
||||
{{% tab name="데비안 기반 배포판" %}}
|
||||
```bash
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
|
|
@ -192,7 +185,7 @@ sudo apt-get install -y kubelet kubeadm kubectl
|
|||
sudo apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
|
||||
{{% tab name="레드햇 기반 배포판" %}}
|
||||
```bash
|
||||
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
|
|
@ -223,7 +216,7 @@ sudo systemctl enable --now kubelet
|
|||
- 구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora CoreOS 또는 Flatcar Container Linux" %}}
|
||||
{{% tab name="패키지 매니저를 사용하지 않는 경우" %}}
|
||||
CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -303,8 +303,9 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
|
|||
다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다.
|
||||
|
||||
* 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다.
|
||||
* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서 작동)
|
||||
* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서는 가능)
|
||||
* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다.
|
||||
* 한 서비스는 최대 64개의 백엔드 파드 또는 고유한 목적지 IP를 지원할 수 있다.
|
||||
* kube-proxy의 오버레이 네트워킹 지원은 알파 릴리스이다. 또한 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 설치해야 한다.
|
||||
* 로컬 트래픽 정책 및 DSR 모드
|
||||
* l2bridge, l2tunnel 또는 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이러한 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다.
|
||||
|
|
|
|||
|
|
@ -353,99 +353,6 @@ exampleWithKubeConfig = do
|
|||
>>= print
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
### 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod}
|
||||
|
||||
파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은
|
||||
위에서 설명한 외부 클라이언트 사례와 약간 다르다.
|
||||
|
||||
파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은
|
||||
공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한
|
||||
라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다.
|
||||
|
||||
#### 공식 클라이언트 라이브러리 사용
|
||||
|
||||
파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다.
|
||||
|
||||
- Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다.
|
||||
`rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다.
|
||||
|
||||
- Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다.
|
||||
`config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다.
|
||||
|
||||
- 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다.
|
||||
|
||||
각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와
|
||||
안전하게 통신하는 데 사용된다.
|
||||
|
||||
#### REST API에 직접 접근
|
||||
|
||||
파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는
|
||||
서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc`
|
||||
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
|
||||
이를 자동으로 수행한다.
|
||||
|
||||
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
자격 증명을 사용하는 것이다. 기본적으로, 파드는
|
||||
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
|
||||
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다.
|
||||
|
||||
사용 가능한 경우, 인증서 번들은 각 컨테이너의
|
||||
파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며,
|
||||
API 서버의 제공 인증서를 확인하는 데 사용해야 한다.
|
||||
|
||||
마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다.
|
||||
|
||||
#### kubectl 프록시 사용
|
||||
|
||||
공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서
|
||||
새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로
|
||||
`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는
|
||||
API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의
|
||||
다른 컨테이너가 직접 사용할 수 있도록 한다.
|
||||
|
||||
#### 프록시를 사용하지 않고 접근
|
||||
|
||||
인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을
|
||||
피할 수 있다. 내부 인증서는 연결을 보호한다.
|
||||
|
||||
```shell
|
||||
# 내부 API 서버 호스트 이름을 가리킨다
|
||||
APISERVER=https://kubernetes.default.svc
|
||||
|
||||
# ServiceAccount 토큰 경로
|
||||
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
|
||||
# 이 파드의 네임스페이스를 읽는다
|
||||
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
|
||||
|
||||
# ServiceAccount 베어러 토큰을 읽는다
|
||||
TOKEN=$(cat ${SERVICEACCOUNT}/token)
|
||||
|
||||
# 내부 인증 기관(CA)을 참조한다
|
||||
CACERT=${SERVICEACCOUNT}/ca.crt
|
||||
|
||||
# TOKEN으로 API를 탐색한다
|
||||
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
* [파드 내에서 쿠버네티스 API에 접근](/ko/docs/tasks/run-application/access-api-from-pod/)
|
||||
|
|
|
|||
|
|
@ -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 인증서를 프로비전 할 수 있다.
|
||||
|
|
@ -70,7 +70,7 @@ content_type: task
|
|||
|
||||
1. 스토리지클래스를 기본값으로 표시한다.
|
||||
|
||||
이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다.
|
||||
이전 과정과 유사하게, 어노테이션을 추가/설정해야 한다.
|
||||
`storageclass.kubernetes.io/is-default-class=true`.
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -70,8 +70,9 @@ weight: 20
|
|||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다.
|
||||
사용하기 전에 순서에 주의한다.
|
||||
환경 변수는 서로를 참조할 수 있는데, 이 때 순서에 주의해야 한다.
|
||||
동일한 컨텍스트에서 정의된 다른 변수를 참조하는 변수는 목록의 뒤쪽에 나와야 한다.
|
||||
또한, 순환 참조는 피해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 설정 안에서 환경 변수 사용하기
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
|
||||
[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
|
||||
[kustomization 파일](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization)을
|
||||
[kustomization 파일](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization)을
|
||||
통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.
|
||||
|
||||
1.14 이후로, kubectl도
|
||||
|
|
|
|||
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
title: 파드 내에서 쿠버네티스 API에 접근
|
||||
content_type: task
|
||||
weight: 120
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 파드 내에서 쿠버네티스 API에 접근하는 방법을 보여준다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod}
|
||||
|
||||
파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은
|
||||
위에서 설명한 외부 클라이언트 사례와 약간 다르다.
|
||||
|
||||
파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은
|
||||
공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한
|
||||
라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다.
|
||||
|
||||
### 공식 클라이언트 라이브러리 사용
|
||||
|
||||
파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다.
|
||||
|
||||
- Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다.
|
||||
`rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다.
|
||||
|
||||
- Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다.
|
||||
`config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
|
||||
[여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다.
|
||||
|
||||
- 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다.
|
||||
|
||||
각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와
|
||||
안전하게 통신하는 데 사용된다.
|
||||
|
||||
### REST API에 직접 접근
|
||||
|
||||
파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는
|
||||
서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc`
|
||||
호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
|
||||
이를 자동으로 수행한다.
|
||||
|
||||
API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
자격 증명을 사용하는 것이다. 기본적으로, 파드는
|
||||
서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
|
||||
해당 파드에 있는 각 컨테이너의 파일시스템 트리의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다.
|
||||
|
||||
사용 가능한 경우, 인증서 번들은 각 컨테이너의
|
||||
파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며,
|
||||
API 서버의 제공 인증서를 확인하는 데 사용해야 한다.
|
||||
|
||||
마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다.
|
||||
|
||||
### kubectl 프록시 사용
|
||||
|
||||
공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서
|
||||
새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로
|
||||
`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는
|
||||
API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의
|
||||
다른 컨테이너가 직접 사용할 수 있도록 한다.
|
||||
|
||||
### 프록시를 사용하지 않고 접근
|
||||
|
||||
인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을
|
||||
피할 수 있다. 내부 인증서는 연결을 보호한다.
|
||||
|
||||
```shell
|
||||
# 내부 API 서버 호스트 이름을 가리킨다
|
||||
APISERVER=https://kubernetes.default.svc
|
||||
|
||||
# 서비스어카운트(ServiceAccount) 토큰 경로
|
||||
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
|
||||
# 이 파드의 네임스페이스를 읽는다
|
||||
NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
|
||||
|
||||
# 서비스어카운트 베어러 토큰을 읽는다
|
||||
TOKEN=$(cat ${SERVICEACCOUNT}/token)
|
||||
|
||||
# 내부 인증 기관(CA)을 참조한다
|
||||
CACERT=${SERVICEACCOUNT}/ca.crt
|
||||
|
||||
# TOKEN으로 API를 탐색한다
|
||||
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
|
@ -70,6 +70,7 @@ kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서
|
|||
|
||||
서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여
|
||||
새로운 인증서 서명 요청을 자동으로 발행한다.
|
||||
이는 인증서 유효 기간이 30%-10% 남은 시점에 언제든지 실행될 수 있다.
|
||||
또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고
|
||||
서명된 인증서를 인증서 서명 요청에 첨부한다.
|
||||
kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다.
|
||||
|
|
|
|||
|
|
@ -7,18 +7,19 @@ no_list: true
|
|||
|
||||
## kubectl
|
||||
|
||||
쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을
|
||||
실행할 수 있다. `kubectl` 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
|
||||
관리하고, 로그를 볼 수 있다.
|
||||
<!-- overview -->
|
||||
쿠버네티스 커맨드 라인 도구인 [`kubectl`](/ko/docs/reference/kubectl/kubectl/)을 사용하면
|
||||
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
|
||||
`kubectl` 을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고,
|
||||
로그를 볼 수 있다. kubectl 전체 명령어를 포함한 추가 정보는
|
||||
[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)에서 확인할 수 있다.
|
||||
|
||||
클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는
|
||||
[`kubectl` 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을
|
||||
참고한다.
|
||||
`kubectl` 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다.
|
||||
각각에 대한 설치 가이드는 다음과 같다.
|
||||
|
||||
<a class="btn btn-primary" href="/ko/docs/tasks/tools/install-kubectl/" role="button" aria-label="kubectl 설치 및 설정 가이드 보기">kubectl 설치 및 설정 가이드 보기</a>
|
||||
|
||||
[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를
|
||||
읽어볼 수도 있다.
|
||||
- [리눅스에 `kubectl` 설치하기](install-kubectl-linux)
|
||||
- [macOS에 `kubectl` 설치하기](install-kubectl-macos)
|
||||
- [윈도우에 `kubectl` 설치하기](install-kubectl-windows)
|
||||
|
||||
## kind
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "포함된 도구들"
|
||||
description: "메인 kubectl-installs-*.md 페이지에 포함될 스니펫."
|
||||
headless: true
|
||||
toc_hide: true
|
||||
---
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: "gcloud kubectl install"
|
||||
description: "gcloud를 이용하여 kubectl을 설치하는 방법을 각 OS별 탭에 포함하기 위한 스니펫."
|
||||
headless: true
|
||||
---
|
||||
|
||||
Google Cloud SDK를 사용하여 kubectl을 설치할 수 있다.
|
||||
|
||||
1. [Google Cloud SDK](https://cloud.google.com/sdk/)를 설치한다.
|
||||
|
||||
1. `kubectl` 설치 명령을 실행한다.
|
||||
|
||||
```shell
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl version --client
|
||||
```
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: "다음 단계는 무엇인가?"
|
||||
description: "kubectl을 설치한 다음 해야 하는 것에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
* [Minikube 설치](https://minikube.sigs.k8s.io/docs/start/)
|
||||
* 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
|
||||
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* 직접 생성하지 않은 클러스터에 접근해야 하는 경우,
|
||||
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
|
||||
* [kubectl 레퍼런스 문서](/ko/docs/reference/kubectl/kubectl/) 읽기
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
title: "리눅스에서 bash 자동 완성 사용하기"
|
||||
description: "리눅스에서 bash 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
### 소개
|
||||
|
||||
Bash의 kubectl 자동 완성 스크립트는 `kubectl completion bash` 명령으로 생성할 수 있다. 셸에서 자동 완성 스크립트를 소싱(sourcing)하면 kubectl 자동 완성 기능이 활성화된다.
|
||||
|
||||
그러나, 자동 완성 스크립트는 [**bash-completion**](https://github.com/scop/bash-completion)에 의존하고 있으며, 이 소프트웨어를 먼저 설치해야 한다(`type _init_completion` 을 실행하여 bash-completion이 이미 설치되어 있는지 확인할 수 있음).
|
||||
|
||||
### bash-completion 설치
|
||||
|
||||
bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](https://github.com/scop/bash-completion#installation) 참고). `apt-get install bash-completion` 또는 `yum install bash-completion` 등으로 설치할 수 있다.
|
||||
|
||||
위의 명령은 bash-completion의 기본 스크립트인 `/usr/share/bash-completion/bash_completion` 을 생성한다. 패키지 관리자에 따라, `~/.bashrc` 파일에서 이 파일을 수동으로 소스(source)해야 한다.
|
||||
|
||||
확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다.
|
||||
|
||||
```bash
|
||||
source /usr/share/bash-completion/bash_completion
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 `type _init_completion` 을 입력하여 bash-completion이 올바르게 설치되었는지 확인한다.
|
||||
|
||||
### kubectl 자동 완성 활성화
|
||||
|
||||
이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
|
||||
|
||||
- `~/.bashrc` 파일에서 자동 완성 스크립트를 소싱한다.
|
||||
|
||||
```bash
|
||||
echo 'source <(kubectl completion bash)' >>~/.bashrc
|
||||
```
|
||||
|
||||
- 자동 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.
|
||||
|
||||
```bash
|
||||
kubectl completion bash >/etc/bash_completion.d/kubectl
|
||||
```
|
||||
|
||||
kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
bash-completion은 `/etc/bash_completion.d` 에 있는 모든 자동 완성 스크립트를 소싱한다.
|
||||
{{< /note >}}
|
||||
|
||||
두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
---
|
||||
title: "macOS에서 bash 자동 완성 사용하기"
|
||||
description: "macOS에서 bash 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
### 소개
|
||||
|
||||
Bash의 kubectl 자동 완성 스크립트는 `kubectl completion bash` 로 생성할 수 있다. 이 스크립트를 셸에 소싱하면 kubectl 자동 완성이 가능하다.
|
||||
|
||||
그러나 kubectl 자동 완성 스크립트는 미리 [**bash-completion**](https://github.com/scop/bash-completion)을 설치해야 동작한다.
|
||||
|
||||
{{< warning>}}
|
||||
bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 자동 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 **작동하지 않는다**. **bash-completion v2** 와 **Bash 4.1 이상 버전** 이 필요하다. 따라서, macOS에서 kubectl 자동 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야 한다([*지침*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다.
|
||||
{{< /warning >}}
|
||||
|
||||
### Bash 업그레이드
|
||||
|
||||
여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.
|
||||
|
||||
```bash
|
||||
echo $BASH_VERSION
|
||||
```
|
||||
|
||||
너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.
|
||||
|
||||
```bash
|
||||
brew install bash
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.
|
||||
|
||||
```bash
|
||||
echo $BASH_VERSION $SHELL
|
||||
```
|
||||
|
||||
Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다.
|
||||
|
||||
### bash-completion 설치
|
||||
|
||||
{{< note >}}
|
||||
언급한 바와 같이, 이 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 이는 bash-completion v2를 설치한다는 것을 의미한다(Bash 3.2 및 bash-completion v1의 경우, kubectl 자동 완성이 작동하지 않음).
|
||||
{{< /note >}}
|
||||
|
||||
bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.
|
||||
|
||||
```bash
|
||||
brew install bash-completion@2
|
||||
```
|
||||
|
||||
이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다.
|
||||
|
||||
```bash
|
||||
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
|
||||
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 bash-completion v2가 올바르게 설치되었는지 `type _init_completion` 으로 확인한다.
|
||||
|
||||
### kubectl 자동 완성 활성화
|
||||
|
||||
이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행하는 방법에는 여러 가지가 있다.
|
||||
|
||||
- 자동 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다.
|
||||
|
||||
```bash
|
||||
echo 'source <(kubectl completion bash)' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- 자동 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다.
|
||||
|
||||
```bash
|
||||
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
|
||||
```
|
||||
|
||||
- kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 자동 완성을 확장할 수 있다.
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bash_profile
|
||||
echo 'complete -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- Homebrew로 kubectl을 설치한 경우([여기](/ko/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)의 설명을 참고), kubectl 자동 완성 스크립트가 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있을 것이다. 이 경우, 아무 것도 할 필요가 없다.
|
||||
|
||||
{{< note >}}
|
||||
bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다.
|
||||
{{< /note >}}
|
||||
|
||||
어떤 경우든, 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: "zsh 자동 완성"
|
||||
description: "zsh 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
Zsh용 kubectl 자동 완성 스크립트는 `kubectl completion zsh` 명령으로 생성할 수 있다. 셸에서 자동 완성 스크립트를 소싱하면 kubectl 자동 완성 기능이 활성화된다.
|
||||
|
||||
모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다.
|
||||
|
||||
```zsh
|
||||
source <(kubectl completion zsh)
|
||||
```
|
||||
|
||||
kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
|
||||
|
||||
```zsh
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
|
||||
셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
|
||||
|
||||
`complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.
|
||||
|
||||
```zsh
|
||||
autoload -Uz compinit
|
||||
compinit
|
||||
```
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: "kubectl 설치 검증하기"
|
||||
description: "kubectl을 검증하는 방법에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
|
||||
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를
|
||||
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
|
||||
[kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)이
|
||||
필요하다.
|
||||
기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
|
||||
|
||||
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
|
||||
|
||||
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
|
||||
|
||||
```
|
||||
The connection to the server <server-name:port> was refused - did you specify the right host or port?
|
||||
```
|
||||
|
||||
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
|
||||
|
||||
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info dump
|
||||
```
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
---
|
||||
|
||||
|
||||
title: 리눅스에 kubectl 설치 및 설정
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: 리눅스에 kubectl 설치하기
|
||||
---
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
|
||||
예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## 리눅스에 kubectl 설치
|
||||
|
||||
다음과 같은 방법으로 리눅스에 kubectl을 설치할 수 있다.
|
||||
|
||||
- [리눅스에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-linux)
|
||||
- [기본 패키지 관리 도구를 사용하여 설치](#install-using-native-package-management)
|
||||
- [다른 패키지 관리 도구를 사용하여 설치](#install-using-other-package-management)
|
||||
- [Google Cloud SDK를 사용하여 설치](#install-on-linux-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-linux}
|
||||
|
||||
1. 다음 명령으로 최신 릴리스를 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
|
||||
|
||||
예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬(checksum) 파일을 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
```bash
|
||||
kubectl: OK
|
||||
```
|
||||
|
||||
검증이 실패한다면, `shasum`이 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
|
||||
|
||||
```bash
|
||||
kubectl: FAILED
|
||||
sha256sum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
동일한 버전의 바이너리와 체크섬을 다운로드한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. kubectl 설치
|
||||
|
||||
```bash
|
||||
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
대상 시스템에 root 접근 권한을 가지고 있지 않더라도, `~/.local/bin` 디렉터리에 kubectl을 설치할 수 있다.
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.local/bin/kubectl
|
||||
mv ./kubectl ~/.local/bin/kubectl
|
||||
# 그리고 ~/.local/bin/kubectl을 $PATH에 추가
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
1. 설치한 버전이 최신인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### 기본 패키지 관리 도구를 사용하여 설치 {#install-using-native-package-management}
|
||||
|
||||
{{< tabs name="kubectl_install" >}}
|
||||
{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubectl
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
EOF
|
||||
yum install -y kubectl
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### 다른 패키지 관리 도구를 사용하여 설치 {#install-using-other-package-management}
|
||||
|
||||
{{< tabs name="other_kubectl_install" >}}
|
||||
{{% tab name="Snap" %}}
|
||||
[snap](https://snapcraft.io/docs/core/install) 패키지 관리자를 지원하는 Ubuntu 또는 다른 리눅스 배포판을 사용하는 경우, kubectl을 [snap](https://snapcraft.io/) 애플리케이션으로 설치할 수 있다.
|
||||
|
||||
```shell
|
||||
snap install kubectl --classic
|
||||
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Homebrew" %}}
|
||||
리눅스 상에서 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 패키지 관리자를 사용한다면, [설치](https://docs.brew.sh/Homebrew-on-Linux#install)를 통해 kubectl을 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
brew install kubectl
|
||||
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Google Cloud SDK를 사용하여 설치 {#install-on-linux-as-part-of-the-google-cloud-sdk}
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## kubectl 구성 확인
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## 선택적 kubectl 구성
|
||||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
{{< tabs name="kubectl_autocompletion" >}}
|
||||
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-linux.md" />}}
|
||||
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
---
|
||||
|
||||
|
||||
title: macOS에 kubectl 설치 및 설정
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: macOS에 kubectl 설치하기
|
||||
---
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
|
||||
예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## macOS에 kubectl 설치
|
||||
|
||||
다음과 같은 방법으로 macOS에 kubectl을 설치할 수 있다.
|
||||
|
||||
- [macOS에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-macos)
|
||||
- [macOS에서 Homebrew를 사용하여 설치](#install-with-homebrew-on-macos)
|
||||
- [macOS에서 Macports를 사용하여 설치](#install-with-macports-on-macos)
|
||||
- [Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### macOS에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-macos}
|
||||
|
||||
1. 최신 릴리스를 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
|
||||
|
||||
예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬 파일을 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
```bash
|
||||
kubectl: OK
|
||||
```
|
||||
|
||||
검증이 실패한다면, `shasum`이 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
|
||||
|
||||
```bash
|
||||
kubectl: FAILED
|
||||
shasum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
동일한 버전의 바이너리와 체크섬을 다운로드한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. kubectl 바이너리를 실행 가능하게 한다.
|
||||
|
||||
```bash
|
||||
chmod +x ./kubectl
|
||||
```
|
||||
|
||||
1. kubectl 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
|
||||
|
||||
```bash
|
||||
sudo mv ./kubectl /usr/local/bin/kubectl && \
|
||||
sudo chown root: /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### macOS에서 Homebrew를 사용하여 설치 {#install-with-homebrew-on-macos}
|
||||
|
||||
macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경우, Homebrew로 kubectl을 설치할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다.
|
||||
|
||||
```bash
|
||||
brew install kubectl
|
||||
```
|
||||
|
||||
또는
|
||||
|
||||
```bash
|
||||
brew install kubernetes-cli
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### macOS에서 Macports를 사용하여 설치 {#install-with-macports-on-macos}
|
||||
|
||||
macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하는 경우, Macports로 kubectl을 설치할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다.
|
||||
|
||||
```bash
|
||||
sudo port selfupdate
|
||||
sudo port install kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
|
||||
### Google Cloud SDK를 사용하여 설치 {#install-on-macos-as-part-of-the-google-cloud-sdk}
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## kubectl 구성 확인
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## 선택적 kubectl 구성
|
||||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
{{< tabs name="kubectl_autocompletion" >}}
|
||||
{{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}}
|
||||
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
|
@ -0,0 +1,179 @@
|
|||
---
|
||||
|
||||
|
||||
title: 윈도우에 kubectl 설치 및 설정
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: 윈도우에 kubectl 설치하기
|
||||
---
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
|
||||
예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
## 윈도우에 kubectl 설치
|
||||
|
||||
다음과 같은 방법으로 윈도우에 kubectl을 설치할 수 있다.
|
||||
|
||||
- [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows)
|
||||
- [PSGallery에서 PowerShell로 설치](#install-with-powershell-from-psgallery)
|
||||
- [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop)
|
||||
- [Google Cloud SDK를 사용하여 설치](#install-on-windows-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
|
||||
### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows}
|
||||
|
||||
1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다.
|
||||
|
||||
또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬 파일을 다운로드한다.
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
|
||||
|
||||
```cmd
|
||||
CertUtil -hashfile kubectl.exe SHA256
|
||||
type kubectl.exe.sha256
|
||||
```
|
||||
|
||||
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
|
||||
```
|
||||
|
||||
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
|
||||
|
||||
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 `PATH` 에 추가한다.
|
||||
도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### PSGallery에서 PowerShell로 설치 {#install-with-powershell-from-psgallery}
|
||||
|
||||
윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다).
|
||||
|
||||
```powershell
|
||||
Install-Script -Name install-kubectl -Scope CurrentUser -Force
|
||||
install-kubectl.ps1 [-DownloadLocation <path>]
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 `temp` 디렉터리에 설치된다.
|
||||
{{< /note >}}
|
||||
|
||||
설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다.
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```powershell
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다.
|
||||
{{< /note >}}
|
||||
|
||||
### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 {#install-on-windows-using-chocolatey-or-scoop}
|
||||
|
||||
1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.
|
||||
|
||||
{{< tabs name="kubectl_win_install" >}}
|
||||
{{% tab name="choco" %}}
|
||||
```powershell
|
||||
choco install kubernetes-cli
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="scoop" %}}
|
||||
```powershell
|
||||
scoop install kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```powershell
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
1. 홈 디렉터리로 이동한다.
|
||||
|
||||
```powershell
|
||||
# cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE%
|
||||
cd ~
|
||||
```
|
||||
|
||||
1. `.kube` 디렉터리를 생성한다.
|
||||
|
||||
```powershell
|
||||
mkdir .kube
|
||||
```
|
||||
|
||||
1. 금방 생성한 `.kube` 디렉터리로 이동한다.
|
||||
|
||||
```powershell
|
||||
cd .kube
|
||||
```
|
||||
|
||||
1. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.
|
||||
|
||||
```powershell
|
||||
New-Item config -type file
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.
|
||||
{{< /note >}}
|
||||
|
||||
### Google Cloud SDK를 사용하여 설치 {#install-on-windows-as-part-of-the-google-cloud-sdk}
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## kubectl 구성 확인
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## 선택적 kubectl 구성
|
||||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
{{< include "included/optional-kubectl-configs-zsh.md" >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
|
@ -1,633 +0,0 @@
|
|||
---
|
||||
|
||||
|
||||
title: kubectl 설치 및 설정
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: kubectl 설치
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
쿠버네티스 커맨드 라인 도구인 [kubectl](/ko/docs/reference/kubectl/kubectl/)을 사용하면,
|
||||
쿠버네티스 클러스터에 대해 명령을 실행할 수 있다.
|
||||
kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하며
|
||||
로그를 볼 수 있다. kubectl 작업의 전체 목록에 대해서는,
|
||||
[kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참고한다.
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다.
|
||||
예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다.
|
||||
최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 리눅스에 kubectl 설치
|
||||
|
||||
### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치
|
||||
|
||||
1. 다음 명령으로 최신 릴리스를 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
|
||||
|
||||
예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬(checksum) 파일을 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
```bash
|
||||
kubectl: OK
|
||||
```
|
||||
|
||||
검증이 실패한다면, `sha256` 가 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
|
||||
|
||||
```bash
|
||||
kubectl: FAILED
|
||||
sha256sum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
동일한 버전의 바이너리와 체크섬을 다운로드한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. kubectl 설치
|
||||
|
||||
```bash
|
||||
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
대상 시스템에 root 접근 권한을 가지고 있지 않더라도, `~/.local/bin` 디렉터리에 kubectl을 설치할 수 있다.
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.local/bin/kubectl
|
||||
mv ./kubectl ~/.local/bin/kubectl
|
||||
# 그리고 ~/.local/bin/kubectl을 $PATH에 추가
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
1. 설치한 버전이 최신인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### 기본 패키지 관리 도구를 사용하여 설치
|
||||
|
||||
{{< tabs name="kubectl_install" >}}
|
||||
{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}}
|
||||
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
|
||||
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y kubectl
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
EOF
|
||||
yum install -y kubectl
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### 다른 패키지 관리 도구를 사용하여 설치
|
||||
|
||||
{{< tabs name="other_kubectl_install" >}}
|
||||
{{% tab name="Snap" %}}
|
||||
[snap](https://snapcraft.io/docs/core/install) 패키지 관리자를 지원하는 Ubuntu 또는 다른 리눅스 배포판을 사용하는 경우, kubectl을 [snap](https://snapcraft.io/) 애플리케이션으로 설치할 수 있다.
|
||||
|
||||
```shell
|
||||
snap install kubectl --classic
|
||||
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Homebrew" %}}
|
||||
리눅스 상에서 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 패키지 관리자를 사용한다면, [설치](https://docs.brew.sh/Homebrew-on-Linux#install)를 통해 kubectl을 사용할 수 있다.
|
||||
|
||||
```shell
|
||||
brew install kubectl
|
||||
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
## macOS에 kubectl 설치
|
||||
|
||||
### macOS에서 curl을 사용하여 kubectl 바이너리 설치
|
||||
|
||||
1. 최신 릴리스를 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
|
||||
|
||||
예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
|
||||
```
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬 파일을 다운로드한다.
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
|
||||
```
|
||||
|
||||
검증이 성공한다면, 출력은 다음과 같다.
|
||||
|
||||
```bash
|
||||
kubectl: OK
|
||||
```
|
||||
|
||||
검증이 실패한다면, `sha256` 가 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
|
||||
|
||||
```bash
|
||||
kubectl: FAILED
|
||||
shasum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
동일한 버전의 바이너리와 체크섬을 다운로드한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. kubectl 바이너리를 실행 가능하게 한다.
|
||||
|
||||
```bash
|
||||
chmod +x ./kubectl
|
||||
```
|
||||
|
||||
1. kubectl 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
|
||||
|
||||
```bash
|
||||
sudo mv ./kubectl /usr/local/bin/kubectl && \
|
||||
sudo chown root: /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### macOS에서 Homebrew를 사용하여 설치
|
||||
|
||||
macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경우, Homebrew로 kubectl을 설치할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다.
|
||||
|
||||
```bash
|
||||
brew install kubectl
|
||||
```
|
||||
|
||||
또는
|
||||
|
||||
```bash
|
||||
brew install kubernetes-cli
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
### macOS에서 Macports를 사용하여 설치
|
||||
|
||||
macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하는 경우, Macports로 kubectl을 설치할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다.
|
||||
|
||||
```bash
|
||||
sudo port selfupdate
|
||||
sudo port install kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
## 윈도우에 kubectl 설치
|
||||
|
||||
### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치
|
||||
|
||||
1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다.
|
||||
|
||||
또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 바이너리를 검증한다. (선택 사항)
|
||||
|
||||
kubectl 체크섬 파일을 다운로드한다.
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
|
||||
```
|
||||
|
||||
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
|
||||
|
||||
- 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
|
||||
|
||||
```cmd
|
||||
CertUtil -hashfile kubectl.exe SHA256
|
||||
type kubectl.exe.sha256
|
||||
```
|
||||
|
||||
- `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
|
||||
```
|
||||
|
||||
1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
|
||||
|
||||
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
|
||||
|
||||
```cmd
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 `PATH` 에 추가한다.
|
||||
도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### PSGallery에서 PowerShell로 설치
|
||||
|
||||
윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.
|
||||
|
||||
1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다).
|
||||
|
||||
```powershell
|
||||
Install-Script -Name install-kubectl -Scope CurrentUser -Force
|
||||
install-kubectl.ps1 [-DownloadLocation <path>]
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 `temp` 디렉터리에 설치된다.
|
||||
{{< /note >}}
|
||||
|
||||
설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다.
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```powershell
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다.
|
||||
{{< /note >}}
|
||||
|
||||
### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치
|
||||
|
||||
1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.
|
||||
|
||||
{{< tabs name="kubectl_win_install" >}}
|
||||
{{% tab name="choco" %}}
|
||||
```powershell
|
||||
choco install kubernetes-cli
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="scoop" %}}
|
||||
```powershell
|
||||
scoop install kubectl
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```powershell
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
1. 홈 디렉터리로 이동한다.
|
||||
|
||||
```powershell
|
||||
# cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE%
|
||||
cd ~
|
||||
```
|
||||
|
||||
1. `.kube` 디렉터리를 생성한다.
|
||||
|
||||
```powershell
|
||||
mkdir .kube
|
||||
```
|
||||
|
||||
1. 금방 생성한 `.kube` 디렉터리로 이동한다.
|
||||
|
||||
```powershell
|
||||
cd .kube
|
||||
```
|
||||
|
||||
1. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.
|
||||
|
||||
```powershell
|
||||
New-Item config -type file
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.
|
||||
{{< /note >}}
|
||||
|
||||
## Google Cloud SDK의 일부로 다운로드
|
||||
|
||||
kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.
|
||||
|
||||
1. [Google Cloud SDK](https://cloud.google.com/sdk/)를 설치한다.
|
||||
|
||||
1. `kubectl` 설치 명령을 실행한다.
|
||||
|
||||
```shell
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
1. 설치한 버전이 최신 버전인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
## kubectl 구성 확인
|
||||
|
||||
kubectl이 쿠버네티스 클러스터를 찾아 접근하려면,
|
||||
[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)를
|
||||
사용하여 클러스터를 생성하거나 Minikube 클러스터를 성공적으로 배포할 때 자동으로 생성되는
|
||||
[kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)이
|
||||
필요하다.
|
||||
기본적으로, kubectl 구성은 `~/.kube/config` 에 있다.
|
||||
|
||||
클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르게 구성된 것이다.
|
||||
|
||||
다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.
|
||||
|
||||
```
|
||||
The connection to the server <server-name:port> was refused - did you specify the right host or port?
|
||||
```
|
||||
|
||||
예를 들어, 랩톱에서 로컬로 쿠버네티스 클러스터를 실행하려면, Minikube와 같은 도구를 먼저 설치한 다음 위에서 언급한 명령을 다시 실행해야 한다.
|
||||
|
||||
kubectl cluster-info가 URL 응답을 반환하지만 클러스터에 접근할 수 없는 경우, 올바르게 구성되었는지 확인하려면 다음을 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl cluster-info dump
|
||||
```
|
||||
|
||||
## 선택적 kubectl 구성
|
||||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Bash(리눅스와 macOS의 다른 점 포함) 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
{{< tabs name="kubectl_autocompletion" >}}
|
||||
|
||||
{{% tab name="리눅스에서의 Bash" %}}
|
||||
|
||||
### 소개
|
||||
|
||||
Bash의 kubectl 완성 스크립트는 `kubectl completion bash` 명령으로 생성할 수 있다. 셸에서 완성 스크립트를 소싱(sourcing)하면 kubectl 자동 완성 기능이 활성화된다.
|
||||
|
||||
그러나, 완성 스크립트는 [**bash-completion**](https://github.com/scop/bash-completion)에 의존하고 있으며, 이 소프트웨어를 먼저 설치해야 한다(`type _init_completion` 을 실행하여 bash-completion이 이미 설치되어 있는지 확인할 수 있음).
|
||||
|
||||
### bash-completion 설치
|
||||
|
||||
bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](https://github.com/scop/bash-completion#installation) 참고). `apt-get install bash-completion` 또는 `yum install bash-completion` 등으로 설치할 수 있다.
|
||||
|
||||
위의 명령은 bash-completion의 기본 스크립트인 `/usr/share/bash-completion/bash_completion` 을 생성한다. 패키지 관리자에 따라, `~/.bashrc` 파일에서 이 파일을 수동으로 소스(source)해야 한다.
|
||||
|
||||
확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다.
|
||||
|
||||
```bash
|
||||
source /usr/share/bash-completion/bash_completion
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 `type _init_completion` 을 입력하여 bash-completion이 올바르게 설치되었는지 확인한다.
|
||||
|
||||
### kubectl 자동 완성 활성화
|
||||
|
||||
이제 kubectl 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
|
||||
|
||||
- `~/.bashrc` 파일에서 완성 스크립트를 소싱한다.
|
||||
|
||||
```bash
|
||||
echo 'source <(kubectl completion bash)' >>~/.bashrc
|
||||
```
|
||||
|
||||
- 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.
|
||||
|
||||
```bash
|
||||
kubectl completion bash >/etc/bash_completion.d/kubectl
|
||||
```
|
||||
|
||||
kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bashrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.bashrc
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
bash-completion은 `/etc/bash_completion.d` 에 있는 모든 완성 스크립트를 소싱한다.
|
||||
{{< /note >}}
|
||||
|
||||
두 방법 모두 동일하다. 셸을 다시 로드한 후, kubectl 자동 완성 기능이 작동해야 한다.
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
|
||||
{{% tab name="macOS에서의 Bash" %}}
|
||||
|
||||
|
||||
### 소개
|
||||
|
||||
Bash의 kubectl 완성 스크립트는 `kubectl completion bash` 로 생성할 수 있다. 이 스크립트를 셸에 소싱하면 kubectl 완성이 가능하다.
|
||||
|
||||
그러나 kubectl 완성 스크립트는 미리 [**bash-completion**](https://github.com/scop/bash-completion)을 설치해야 동작한다.
|
||||
|
||||
{{< warning>}}
|
||||
bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS의 기본 설치 버전) 버전용이고, v2는 Bash 4.1 이상 버전용이다. kubectl 완성 스크립트는 bash-completion v1과 Bash 3.2 버전에서는 **작동하지 않는다**. **bash-completion v2** 와 **Bash 4.1 이상 버전** 이 필요하다. 따라서, macOS에서 kubectl 완성 기능을 올바르게 사용하려면, Bash 4.1 이상을 설치하고 사용해야한다([*지침*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). 다음의 내용에서는 Bash 4.1 이상(즉, 모든 Bash 버전 4.1 이상)을 사용한다고 가정한다.
|
||||
{{< /warning >}}
|
||||
|
||||
### Bash 업그레이드
|
||||
|
||||
여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.
|
||||
|
||||
```bash
|
||||
echo $BASH_VERSION
|
||||
```
|
||||
|
||||
너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.
|
||||
|
||||
```bash
|
||||
brew install bash
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.
|
||||
|
||||
```bash
|
||||
echo $BASH_VERSION $SHELL
|
||||
```
|
||||
|
||||
Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다.
|
||||
|
||||
### bash-completion 설치
|
||||
|
||||
{{< note >}}
|
||||
언급한 바와 같이, 이 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 이는 bash-completion v2를 설치한다는 것을 의미한다(Bash 3.2 및 bash-completion v1의 경우, kubectl 완성이 작동하지 않음).
|
||||
{{< /note >}}
|
||||
|
||||
bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.
|
||||
|
||||
```bash
|
||||
brew install bash-completion@2
|
||||
```
|
||||
|
||||
이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다.
|
||||
|
||||
```bash
|
||||
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
|
||||
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
|
||||
```
|
||||
|
||||
셸을 다시 로드하고 bash-completion v2가 올바르게 설치되었는지 `type _init_completion` 으로 확인한다.
|
||||
|
||||
### kubectl 자동 완성 활성화
|
||||
|
||||
이제 kubectl 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행하는 방법에는 여러 가지가 있다.
|
||||
|
||||
- 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다.
|
||||
|
||||
```bash
|
||||
echo 'source <(kubectl completion bash)' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다.
|
||||
|
||||
```bash
|
||||
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
|
||||
```
|
||||
|
||||
- kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다.
|
||||
|
||||
```bash
|
||||
echo 'alias k=kubectl' >>~/.bash_profile
|
||||
echo 'complete -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다.
|
||||
|
||||
{{< note >}}
|
||||
bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다.
|
||||
{{< /note >}}
|
||||
|
||||
어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Zsh" %}}
|
||||
|
||||
Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생성할 수 있다. 셸에서 완성 스크립트를 소싱하면 kubectl 자동 완성 기능이 활성화된다.
|
||||
|
||||
모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다.
|
||||
|
||||
```zsh
|
||||
source <(kubectl completion zsh)
|
||||
```
|
||||
|
||||
kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.
|
||||
|
||||
```zsh
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
|
||||
셸을 다시 로드 한 후, kubectl 자동 완성 기능이 작동해야 한다.
|
||||
|
||||
`complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.
|
||||
|
||||
```zsh
|
||||
autoload -Uz compinit
|
||||
compinit
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Minikube 설치](https://minikube.sigs.k8s.io/docs/start/)
|
||||
* 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다.
|
||||
* [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
* 직접 생성하지 않은 클러스터에 접근해야하는 경우,
|
||||
[클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
|
||||
* [kubectl 레퍼런스 문서](/ko/docs/reference/kubectl/kubectl/) 읽기
|
||||
|
|
@ -61,6 +61,22 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
|
|||
|
||||
4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭.
|
||||
|
||||
{{< note >}}
|
||||
`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다. 대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다.
|
||||
|
||||
root 환경에서 명령어를 실행하고 있다면, [URL을 이용하여 대시보드 접속하기](#open-dashboard-with-url)를 참고한다.
|
||||
|
||||
`Ctrl+C` 를 눌러 프록시를 종료할 수 있다. 대시보드는 종료되지 않고 실행 상태로 남아 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## URL을 이용하여 대시보드 접속하기 {#open-dashboard-with-url}
|
||||
|
||||
자동으로 웹 브라우저가 열리는 것을 원치 않는다면, 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다:
|
||||
|
||||
```shell
|
||||
minikube dashboard --url
|
||||
```
|
||||
|
||||
## 디플로이먼트 만들기
|
||||
|
||||
쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/)는 관리와
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ weight: 10
|
|||
</p>
|
||||
<p>쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
|
||||
<ul>
|
||||
<li><b>마스터</b>는 클러스터를 조율한다.</li>
|
||||
<li><b>컨트롤 플레인</b>은 클러스터를 조율한다.</li>
|
||||
<li><b>노드</b>는 애플리케이션을 구동하는 작업자(worker)이다.</li>
|
||||
</ul>
|
||||
</p>
|
||||
|
|
@ -71,20 +71,20 @@ weight: 10
|
|||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p><b>마스터는 클러스터 관리를 담당한다.</b> 마스터는 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
|
||||
<p><b>컨트롤 플레인은 클러스터 관리를 담당한다.</b> 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>마스터는 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다. </i></p>
|
||||
<p><i>컨트롤 플레인은 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다. </i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>애플리케이션을 쿠버네티스에 배포하기 위해서는, 마스터에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. <b>노드는 마스터가 제공하는 <a href="/ko/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.</p>
|
||||
<p>애플리케이션을 쿠버네티스에 배포하기 위해서는, 컨트롤 플레인에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 컨트롤 플레인은 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. <b>노드는 컨트롤 플레인이 제공하는 <a href="/ko/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 컨트롤 플레인과 통신한다.</b> 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.</p>
|
||||
|
||||
<p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube를 사용할 수 있다. Minikube는 가벼운 쿠버네티스 구현체이며, 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성한다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑(bootstrapping) 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다.</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ weight: 10
|
|||
일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다.
|
||||
그러기 위해서, 쿠버네티스 <b>디플로이먼트</b> 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가
|
||||
애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면,
|
||||
쿠버네티스 마스터가 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
|
||||
쿠버네티스 컨트롤 플레인이 해당 디플로이먼트에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄한다.
|
||||
</p>
|
||||
|
||||
<p>애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를
|
||||
|
|
|
|||
|
|
@ -412,7 +412,7 @@ client_address=198.51.100.79
|
|||
HTTP [Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)
|
||||
또는 [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)
|
||||
헤더 또는
|
||||
[프록시 프로토콜](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)과
|
||||
[프록시 프로토콜](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)과
|
||||
같은 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다.
|
||||
두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
|
||||
HTTP 헬스 체크를 생성하여
|
||||
|
|
|
|||
|
|
@ -921,7 +921,7 @@ web-2 0/1 Terminating 0 3m
|
|||
|
||||
`web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다.
|
||||
`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
|
||||
전환될 때는 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
|
||||
전환될 때는 이 파드에 적용됐다. 스테이트풀셋에 `replicas`를 2로 하고
|
||||
`web-0`을 재생성했다면 `web-1`이
|
||||
이미 Running과 Ready 상태이고,
|
||||
`web-2`은 종료되었을 것이다.
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ cassandra ClusterIP None <none> 9042/TCP 45s
|
|||
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
|
||||
```
|
||||
|
||||
클러스터에 맞게 `cassandra-statefulset.yaml` 를 수정해야 하는 경우 다음을 다운로드 한 다음
|
||||
클러스터에 맞게 `cassandra-statefulset.yaml` 를 수정해야 하는 경우 다음을 다운로드한 다음
|
||||
수정된 버전을 저장한 폴더에서 해당 매니페스트를 적용한다.
|
||||
https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment
|
|||
1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=guestbook -l tier=frontend
|
||||
kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend
|
||||
```
|
||||
|
||||
결과는 아래와 같은 형태로 나타난다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue