whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #27133 from kubernetes/dev-1.20-ko.6

Browse Source 
[ko] Sixth Korean l10n work for release-1.20
This commit is contained in:
Kubernetes Prow Robot
2021-03-19 05:02:33 -07:00
committed by GitHub
parent 0a6e7bf8f4 94e3f1775a
commit 8c837edc4b
56 changed files with 1308 additions and 1062 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/controller.md
+1 -1
View File
@@ -102,7 +102,7 @@ weight: 30
온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가
서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는
[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API들 및
IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및
기타 서비스 등과 간접적으로 연동하여 이를 구현한다.
## 의도한 상태와 현재 상태 {#desired-vs-current}
content/ko/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -57,7 +57,7 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
정상적인지 확인한다.
상태 확인을 중지하려면 사용자 또는 {{< glossary_tooltip term_id="controller" text="컨트롤러">}}에서
노드 오브젝트를 명시적으로 삭제해야한다.
노드 오브젝트를 명시적으로 삭제해야 한다.
{{< /note >}}
노드 오브젝트의 이름은 유효한
content/ko/docs/concepts/cluster-administration/_index.md
+5 -1
View File
@@ -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으로 관리하는 컨테이너에 대한 환경을 설명한다.
content/ko/docs/concepts/cluster-administration/certificates.md
+1 -242
View File
@@ -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/)를 참고한다.
content/ko/docs/concepts/containers/container-environment.md
+9 -7
View File
@@ -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/)
실제 경험 얻기.
content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+4 -2
View File
@@ -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" %}}
content/ko/docs/concepts/extend-kubernetes/operator.md
+1 -1
View File
@@ -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) 읽기
content/ko/docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -55,7 +55,7 @@ sitemap:
## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
content/ko/docs/concepts/overview/working-with-objects/labels.md
+5
View File
@@ -52,6 +52,11 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하 여야 하고(공백이면 안 됨),
* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
content/ko/docs/concepts/policy/resource-quotas.md
+1 -1
View File
@@ -58,7 +58,7 @@ weight: 20
## 리소스 쿼터 활성화
많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다.
API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로
`ResourceQuota`가 있는 경우 활성화된다.
해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에
content/ko/docs/concepts/services-networking/dns-pod-service.md
+45 -14
View File
@@ -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)를 본다.
## 서비스
content/ko/docs/concepts/services-networking/ingress-controllers.md
+1 -1
View File
@@ -66,7 +66,7 @@ weight: 40
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
{{< note >}}
인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다.
인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야 한다.
{{< /note >}}
content/ko/docs/concepts/services-networking/service.md
+2 -2
View File
@@ -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를 받도록 하기 위해, 내부 할당기는
content/ko/docs/concepts/storage/volume-snapshot-classes.md
+1 -1
View File
@@ -68,7 +68,7 @@ parameters:
### 드라이버
볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다.
결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야 한다.
### 삭제정책(DeletionPolicy)
content/ko/docs/concepts/storage/volumes.md
+1 -1
View File
@@ -1332,7 +1332,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
* `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume`
그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는
민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는
선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다.
* `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해
CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿
content/ko/docs/concepts/workloads/controllers/deployment.md
+2 -2
View File
@@ -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` 만 허용되고,
명시되지 않으면 기본값이 된다.
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+1 -1
View File
@@ -49,7 +49,7 @@ kubectl 명령에서 숏컷으로 사용된다.
{{< codenew file="controllers/replication.yaml" >}}
예제 파일을 다운로드 한 후 다음 명령을 실행하여 예제 작업을 실행하라.
예제 파일을 다운로드한 후 다음 명령을 실행하여 예제 작업을 실행하라.
```shell
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
content/ko/docs/concepts/workloads/controllers/statefulset.md
+2 -2
View File
@@ -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` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
이것은 반드시 수동으로 해야한다.
이것은 반드시 수동으로 해야 한다.
### 파드 이름 레이블
content/ko/docs/concepts/workloads/pods/disruptions.md
+1 -1
View File
@@ -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` 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -2
View File
@@ -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="컨트롤러" >}}라
부르는 하이-레벨 추상화를 사용하여