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

Eighth Korean l10n work for release 1.18

Browse Source 
- Translate tasks/administer-cluster/declare-network-policy in Korean (#22526)
- Translate tasks/debug-application-cluster/debug-init-containers in Korean (#22608)
- Fix a missing markdown syntax to enable external link (#22661)
- Translate tasks/administer-cluster/change-pv-reclaim-policy in Korean (#22551)
- Update docs/contribute/participate/ for Korean (#22605)
- Update outdated files in dev-1.18-ko.8 (#22466)
- Translate tasks/administer-cluster/dns-custom-nameservers in Korean (#22524)

Co-authored-by: Daehyun Paik <paik@a30a.dev>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
bluefriday
2020-07-15 10:59:52 +09:00
committed by June Yi
parent 6bf2feba74
commit fe296af187
46 changed files with 1454 additions and 654 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/_index.md
-4
View File
@@ -11,9 +11,5 @@ content_type: concept
보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은
시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다.
## {{% heading "whatsnext" %}}
만약 태스크 페이지를 작성하고 싶다면,
[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다.
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
+6 -6
View File
@@ -97,12 +97,12 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
예를 들면:
```conf
release=1.0
tier=frontend
environment=pod
track=stable
```
```conf
release=1.0
tier=frontend
environment=pod
track=stable
```
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+97
View File
@@ -0,0 +1,97 @@
---
title: 퍼시스턴트볼륨 반환 정책 변경하기
content_type: task
---
<!-- overview -->
이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
변경하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우
기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다.
볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다.
이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다.
"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는
`PersistentVolume` 은 삭제되지 않는다.
대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다.
## 퍼시스턴트볼륨 반환 정책 변경하기
1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다.
```shell
kubectl get pv
```
결과는 아래와 같다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
```shell
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
```
`<your-pv-name>` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다.
{{< note >}}
윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다.
```cmd
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
```
{{< /note >}}
1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다.
```shell
kubectl get pv
```
결과는 아래와 같다.
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
볼륨은 자동으로 삭제 되지 않는다.
## {{% heading "whatsnext" %}}
* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기.
* [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기.
### Reference
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.
content/ko/docs/tasks/administer-cluster/declare-network-policy.md
+145
View File
@@ -0,0 +1,145 @@
---
title: 네트워크 폴리시(Network Policy) 선언하기
min-kubernetes-server-version: v1.8
content_type: task
---
<!-- overview -->
이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다.
* [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
* [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
* [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
{{< note >}}
위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다.
{{< /note >}}
<!-- steps -->
## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기
쿠버네티스 네트워크 폴리시가 어떻게 동작하는지 확인하기 위해서, `nginx` 디플로이먼트를 생성한다.
```console
kubectl create deployment nginx --image=nginx
```
```none
deployment.apps/nginx created
```
`nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다.
```console
kubectl expose deployment nginx --port=80
```
```none
service/nginx exposed
```
위 명령어들은 nginx 파드에 대한 디플로이먼트를 생성하고, `nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. `nginx` 파드와 디플로이먼트는 `default` 네임스페이스(namespace)에 존재한다.
```console
kubectl get svc,pod
```
```none
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes 10.100.0.1 <none> 443/TCP 46m
service/nginx 10.100.0.16 <none> 80/TCP 33s
NAME READY STATUS RESTARTS AGE
pod/nginx-701339712-e0qfq 1/1 Running 0 35s
```
## 다른 파드에서 접근하여 서비스 테스트하기
사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다.
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```
## `nginx` 서비스에 대해 접근 제한하기
`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다.
{{< codenew file="service/networking/nginx-policy.yaml" >}}
네트워크폴리시 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
{{< note >}}
네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 `podSelector` 를 포함한다. 사용자는 이 정책이 `app=nginx` 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 `nginx` 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
{{< /note >}}
## 서비스에 정책 할당하기
kubectl을 사용하여 위 `nginx-policy.yaml` 파일로부터 네트워크폴리시를 생성한다.
```console
kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
```
```none
networkpolicy.networking.k8s.io/access-nginx created
```
## access 레이블이 정의되지 않은 서비스에 접근 테스트
올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다.
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
wget: download timed out
```
## 접근 레이블을 정의하고 다시 테스트
사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다.
```console
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
```
사용자 쉘에서, 다음의 명령을 실행한다.
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+261
View File
@@ -0,0 +1,261 @@
---
title: DNS 서비스 사용자 정의하기
content_type: task
min-kubernetes-server-version: v1.12
---
<!-- overview -->
이 페이지는 클러스터 안에서 사용자의
DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고
DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
클러스터는 CoreDNS 애드온을 구동하고 있어야 한다.
[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기)
는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다.
{{% version-check %}}
<!-- steps -->
## 소개
DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우,
CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다.
{{< note >}}
CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다.
이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다.
{{< /note >}}
CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다.
Kubelet 은 `--cluster-dns=<dns-service-ip>` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다.
DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=<default-local-domain>` 플래그를
통하여 로컬 도메인을 설정할 수 있다.
DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다.
더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다.
만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우,
파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다.
파드의 DNS 변환도 노드와 동일하게 작동해야 한다.
그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다.
만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우,
사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다.
파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다.
DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다.
## CoreDNS
CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다.
### CoreDNS 컨피그맵(ConfigMap) 옵션
CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다.
이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다.
클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여
해당 클러스터에 대한 DNS 서비스 검색 동작을
변경할 수 있다.
쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
```
Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다.
* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다.
* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다.
* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다.
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다.
`pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다.
* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다.
* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다.
* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다.
* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다.
* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다.
* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다.
사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다.
### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정
CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다.
#### 예시
만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다.
```
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
```
모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다.
```
forward . 172.16.0.1
```
기본 `Corefile` 구성에 따른 최종 컨피그맵은 다음과 같다.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . 172.16.0.1
cache 30
loop
reload
loadbalance
}
consul.local:53 {
errors
cache 30
forward . 10.150.0.1
}
```
`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의
자동 변환을 지원한다.
{{< note >}}
kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다.
변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다.
{{< /note >}}
## kube-dns에 대응되는 CoreDNS 설정
CoreDNS는 kube-dns 이상의 기능을 지원한다.
`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다.
마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다.
### 예시
kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다.
```yaml
apiVersion: v1
data:
federations: |
{"foo" : "foo.feddomain.com"}
stubDomains: |
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
kind: ConfigMap
```
CoreDNS에서는 동등한 설정으로 Corefile을 생성한다.
* federations 에 대응하는 설정:
```
federation cluster.local {
foo foo.feddomain.com
}
```
* stubDomains 에 대응하는 설정:
```yaml
abc.com:53 {
errors
cache 30
forward . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
forward . 2.3.4.5
}
```
기본 플러그인으로 구성된 완전한 Corefile.
```
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
federation cluster.local {
foo foo.feddomain.com
}
prometheus :9153
forward . 8.8.8.8 8.8.4.4
cache 30
}
abc.com:53 {
errors
cache 30
forward . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
forward . 2.3.4.5
}
```
## CoreDNS로의 이관
kube-dns에서 CoreDNS로 이관하기 위하여,
kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는
[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다.
또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를
사용하여 이관할 수도 있다.
## {{% heading "whatsnext" %}}
- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기
content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md
+125
View File
@@ -0,0 +1,125 @@
---
title: 초기화 컨테이너(Init Containers) 디버그하기
content_type: task
---
<!-- overview -->
이 페이지는 초기화 컨테이너의 실행과 관련된 문제를
조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `<pod-name>` 으로,
초기화 컨테이너를 `<init-container-1>` 과
`<init-container-2>` 로 표시한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의
기본 사항에 익숙해야 한다.
* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다.
<!-- steps -->
## 초기화 컨테이너의 상태 체크하기
사용자 파드의 상태를 표시한다.
```shell
kubectl get pod <pod-name>
```
예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중
하나가 성공적으로 완료되었음을 나타낸다.
```
NAME READY STATUS RESTARTS AGE
<pod-name> 0/1 Init:1/2 0 7s
```
상태값과 그 의미에 대한 추가 예제는
[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다.
## 초기화 컨테이너에 대한 상세 정보 조회하기
초기화 컨테이너의 실행에 대한 상세 정보를 확인한다.
```shell
kubectl describe pod <pod-name>
```
예를 들어, 2개의 초기화 컨테이너가 있는 파드는 다음과 같이 표시될 수 있다.
```
Init Containers:
<init-container-1>:
Container ID: ...
...
State: Terminated
Reason: Completed
Exit Code: 0
Started: ...
Finished: ...
Ready: True
Restart Count: 0
...
<init-container-2>:
Container ID: ...
...
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: ...
Finished: ...
Ready: False
Restart Count: 3
...
```
파드 스펙의 `status.initContainerStatuses` 필드를 읽어서
프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다.
```shell
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
```
이 명령은 원시 JSON 방식으로 위와 동일한 정보를 반환한다.
## 초기화 컨테이너의 로그 조회하기
초기화 컨테이너의 로그를 확인하기 위해
파드의 이름과 초기화 컨테이너의 이름을 같이 전달한다.
```shell
kubectl logs <pod-name> -c <init-container-2>
```
셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가
실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에
`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다.
<!-- discussion -->
## 파드의 상태 이해하기
`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의
실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는
동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다.
상태 | 의미
------ | -------
`Init:N/M` | 파드가 `M` 개의 초기화 컨테이너를 갖고 있으며, 현재까지 `N` 개가 완료.
`Init:Error` | 초기화 컨테이너 실행 실패.
`Init:CrashLoopBackOff` | 초기화 컨테이너가 반복적으로 실행 실패.
`Pending` | 파드가 아직 초기화 컨테이너를 실행하지 않음.
`PodInitializing` or `Running` | 파드가 이미 초기화 컨테이너 실행을 완료.