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

Seventh Korean L10n Work for Release 1.16 (#18494)

Browse Source 
* (fix) Broken links in Korean documentation. (#18179)
* Modified link between Korean documents. (#18152)
* Update to outdated files in the dev-1.16-ko.7 (#18146)
* Updates to documents that do not reflect the original text - 1.16 (#18166)
* Update path of referenced links in translated documents - 1.16. (#18164)

Co-Authored-By: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>

Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
This commit is contained in:
June Yi
2020-01-07 07:04:17 +09:00
committed by Kubernetes Prow Robot
parent c2ff814a1c
commit 21f774fd23
76 changed files with 343 additions and 198 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/_index.md
+1 -1
View File
@@ -35,7 +35,7 @@ weight: 40
* [볼륨](/docs/concepts/storage/volumes/)
* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
content/ko/docs/concepts/architecture/cloud-controller.md
+1 -1
View File
@@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
{{< /note >}}
CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
content/ko/docs/concepts/architecture/master-node-communication.md
+31 -14
View File
@@ -6,10 +6,11 @@ weight: 20
{{% capture overview %}}
이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다.
그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서
(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는
그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다.
이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의
커뮤니케이션 경로를 나열해 본다. 그 목적은 신뢰할 수 없는 네트워크
(또는 클라우드 제공자의 공인 IP만으로 구성된 네트워크)에서도 동작될 수 있는
클러스터 구축을 위해, 네트워크의 구성을 강화하는 사용자
맞춤형 설치를 허용하기 위함이다.
{{% /capture %}}
@@ -20,23 +21,27 @@ weight: 20
클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다
(어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다).
전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형태가
전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트
[인증](/docs/reference/access-authn-authz/authentication/) 형태가
사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다.
특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이
허용된 경우에는 하나 또는 그 이상의 [인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
허용된 경우에는 하나 또는 그 이상의
[인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는
그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다.
예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은
클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에 대한 자동화 프로비저닝에 대해서는
클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에
대한 자동화 프로비저닝에 대해서는
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게
그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와
유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다.
(모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로
(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를 가지고 구성된다.
(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를
가지고 구성된다.
마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다.
@@ -68,7 +73,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을
apiserver와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/master-node-communication/#SSH-터널)을
사용한다.
마지막으로, kubelet API를 안전하게 하기 위해
@@ -77,12 +82,24 @@ apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/maste
### apiserver에서 노드, 파드, 그리고 서비스로
apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을
기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에
`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만,
HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
클라이언트 자격증명 또한 제공하지 않는다.
기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드,
파드, 또는 서비스 이름에 `https:` 프리픽스를 붙임으로써 안전한 HTTPS
연결로 동작될 수 있지만, HTTPS 엔드포인트에 의해 제공되는
인증서를 확인하지 않으며 클라이언트 자격증명 또한 제공하지 않는다.
그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다.
이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
이러한 연결들은 신뢰할 수 없는 그리고/또는 공인
네트워크에서 동작하기에
**현재로서는 안전하지 않다**.
### SSH 터널
쿠버네티스는 마스터 -> 클러스터 통신 경로를 보호하는 SSH 터널을
지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
않도록 보장한다.
SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는 한 터널을 이용하지 말아야 한다. 이 통신 채널의 대체물을 설계 중이다.
{{% /capture %}}
content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md
+2 -2
View File
@@ -41,7 +41,7 @@ weight: 10
* [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
* [쿠버네티스 컨테이너 환경](/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다.
@@ -62,7 +62,7 @@ weight: 10
## 선택적 클러스터 서비스
* [DNS 통합](/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
* [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.
content/ko/docs/concepts/configuration/overview.md
+5 -5
View File
@@ -30,9 +30,9 @@ weight: 10
## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
## 서비스
@@ -62,9 +62,9 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
## 레이블 사용하기
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
@@ -100,7 +100,7 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
- 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
content/ko/docs/concepts/containers/container-environment-variables.md
+2 -2
View File
@@ -17,7 +17,7 @@ weight: 20
쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다.
* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
* 하나의 [이미지](/ko/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
* 컨테이너 자신에 대한 정보.
* 클러스터 내의 다른 오브젝트에 대한 정보.
@@ -54,7 +54,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
{{% capture whatsnext %}}
* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.
{{% /capture %}}
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+2 -2
View File
@@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
파라미터는 핸들러에 전달되지 않는다.
종료 동작에 더 자세한 대한 설명은
[파드의 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)에서 찾을 수 있다.
[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다.
### 훅 핸들러 구현
@@ -113,7 +113,7 @@ Events:
{{% capture whatsnext %}}
* [컨테이너 환경](/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
실습 경험하기.
content/ko/docs/concepts/containers/images.md
+2 -2
View File
@@ -26,7 +26,7 @@ weight: 10
- `imagePullPolicy`와 사용할 이미지의 태그를 생략.
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/docs/concepts/configuration/overview/#container-images)를 참고한다.
`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다.
## 매니페스트로 멀티-아키텍처 이미지 빌드
@@ -141,7 +141,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
* `DOCKER_EMAIL`: `${some-email-address}`
해당 변수에 대한 값을 채우고 나면
[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)할 수 있다.
[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다.
### IBM 클라우드 컨테이너 레지스트리 사용
IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로,
content/ko/docs/concepts/overview/components.md
+1 -1
View File
@@ -121,7 +121,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
{{% /capture %}}
{{% capture whatsnext %}}
* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
* [컨트롤러](/docs/concepts/architecture/controller/)에 대해 더 배우기
* [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
* etcd의 공식 [문서](https://etcd.io/docs/) 읽기
{{% /capture %}}
content/ko/docs/concepts/overview/what-is-kubernetes.md
+3 -3
View File
@@ -64,7 +64,7 @@ card:
* **자동화된 복구(self-healing)**
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
* **시크릿과 구성 관리**
쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
## 쿠버네티스가 아닌 것
@@ -74,9 +74,9 @@ card:
* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
content/ko/docs/concepts/overview/working-with-objects/annotations.md
+1 -1
View File
@@ -91,7 +91,7 @@ spec:
{{% /capture %}}
{{% capture whatsnext %}}
[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
[레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+1 -1
View File
@@ -74,7 +74,7 @@ deployment.apps/nginx-deployment created
{{% capture whatsnext %}}
* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
* 쿠버네티스의 [컨트롤러](/docs/concepts/architecture/controller/)에 대해 배운다.
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/labels.md
+4 -4
View File
@@ -20,7 +20,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
}
```
레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
{{% /capture %}}
@@ -75,7 +75,7 @@ spec:
## 레이블 셀렉터
[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
[이름과 UID](/ko/docs/concepts/overview/working-with-objects/names/)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.
@@ -184,7 +184,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
### API 오브젝트에서 참조 설정
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
#### 서비스와 레플리케이션 컨트롤러
@@ -209,7 +209,7 @@ selector:
#### 세트-기반 요건을 지원하는 리소스
[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
```yaml
selector:
content/ko/docs/concepts/overview/working-with-objects/names.md
+1 -1
View File
@@ -11,7 +11,7 @@ weight: 20
예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.
유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+1 -1
View File
@@ -84,7 +84,7 @@ kubectl config view --minify | grep namespace:
## 네임스페이스와 DNS
[서비스](/docs/user-guide/services)를 생성하면, 대응되는
[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
content/ko/docs/concepts/services-networking/ingress-controllers.md
+1 -1
View File
@@ -55,7 +55,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
{{% capture whatsnext %}}
* [인그레스](/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
{{% /capture %}}
content/ko/docs/concepts/services-networking/ingress.md
+8 -8
View File
@@ -44,7 +44,7 @@ weight: 40
[ Services ]
```
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
@@ -52,10 +52,10 @@ weight: 40
## 전제 조건들
[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러
[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스
컨트롤러는 조금 다르게 작동한다.
@@ -89,7 +89,7 @@ spec:
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
다른 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@@ -117,7 +117,7 @@ spec:
### 기본 벡엔드
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
백엔드는 일반적으로 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
@@ -218,7 +218,7 @@ Events:
볼 수 있다.
{{< note >}}
사용중인 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)
사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
에 따라 default-http-backend
[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
{{< /note >}}
@@ -452,7 +452,7 @@ Events:
## 가용성 영역에 전체에서의 실패
장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
자세한 내용은 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
를 참조할 수 있다.
## 앞으로의 할일
@@ -472,6 +472,6 @@ Events:
{{% /capture %}}
{{% capture whatsnext %}}
* [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}
content/ko/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
content/ko/docs/concepts/workloads/controllers/replicaset.md
+1 -1
View File
@@ -277,7 +277,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다.
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
### 레플리카셋에서 파드 격리
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+7 -7
View File
@@ -16,7 +16,7 @@ weight: 20
{{% capture overview %}}
{{< note >}}
[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
{{< /note >}}
_레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가
@@ -143,7 +143,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
### 파드 셀렉터
`.spec.selector` 필드는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
레플리케이션 컨트롤러를 교체할 수 있다.
@@ -257,14 +257,14 @@ API 오브젝트에 대한 더 자세한 것은
### 레플리카셋
[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 이다.
이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
### 디플로이먼트 (권장되는)
[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
`kubectl rolling-update` 와는 다르게 선언적이며, 서버 사이드이고,
추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
@@ -280,12 +280,12 @@ API 오브젝트에 대한 더 자세한 것은
### 데몬셋
머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
## 더 자세한 정보는
[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
{{% /capture %}}
content/ko/docs/concepts/workloads/controllers/statefulset.md
+8 -6
View File
@@ -44,10 +44,6 @@ weight: 40
## 구성 요소
아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
```yaml
apiVersion: v1
kind: Service
@@ -99,6 +95,12 @@ spec:
storage: 1Gi
```
위의 예시에서:
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
## 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
아니라면 `cluster.local`로 설정된다.
{{< /note >}}
@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
{{% /capture %}}
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+2 -3
View File
@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
`TTLAfterFinished` 를 통해 활성화 될 수 있다.
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
{{% /capture %}}
content/ko/docs/concepts/workloads/pods/disruptions.md
+2 -2
View File
@@ -68,7 +68,7 @@ weight: 60
- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는
영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에
영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에
애플리케이션을 분산해야 한다.
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
@@ -116,7 +116,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.)
([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)
파드를 Eviction API로 축출하면 정상적으로 종료된다.
([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+8 -8
View File
@@ -65,7 +65,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수
* `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음.
* `Ready`: 파드는 요청들을 수행할 수 있으며
모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
* `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가
* `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
성공적으로 시작 완료되었음.
* `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서
지금 당장은 파드를 스케줄할 수 없음.
@@ -243,7 +243,7 @@ status:
```
파드의 새로운 조건들은
쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다.
쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다.
`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에,
새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다.
@@ -271,7 +271,7 @@ PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으
kubelet에 의해서 재시작되는 종료된 컨테이너는
5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며,
10분의 성공적 실행 후에 재설정된다.
[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이,
[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이,
파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다.
@@ -290,13 +290,13 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는
지정된 경우에 적합하다.
- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는
[레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
[레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는
[디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
[레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
[레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된
경우에만 적합하다.
- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길
- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길
바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다.
세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를
@@ -401,7 +401,7 @@ spec:
* Hands-on 경험하기
[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
{{% /capture %}}
content/ko/docs/concepts/workloads/pods/pod-overview.md
+9 -9
View File
@@ -31,7 +31,7 @@ card:
* [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.
## 어떻게 파드가 다중 컨테이너를 관리하는가
@@ -61,7 +61,7 @@ card:
파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
{{< /note >}}
파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.
### 파드와 컨트롤러
@@ -69,17 +69,17 @@ card:
한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.
* [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)
* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/)
* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)
* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다.
## 파드 템플릿
파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/),
[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다.
@@ -102,8 +102,8 @@ spec:
{{% /capture %}}
{{% capture whatsnext %}}
* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
* 파드의 동작에 대해 더 알아보자.
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
* [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
{{% /capture %}}
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+1 -1
View File
@@ -144,7 +144,7 @@ spec:
+---------------+-------+
| zoneA | zoneB |
+-------+-------+-------+
| node1 | node2 | nod3 |
| node1 | node2 | node3 |
+-------+-------+-------+
| P P | P | P P |
+-------+-------+-------+
content/ko/docs/concepts/workloads/pods/pod.md
+5 -5
View File
@@ -45,13 +45,13 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
도커 컨테이너 그룹으로 모델링 된다.
개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
[파드의 생애](/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
파드가 만들어지고 고유한 ID(UID)가 할당되고,
재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
더 자세한 내용은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
볼륨과 같이 파드와 동일한 수명이 있다고 하면,
UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다.
@@ -133,10 +133,10 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
일반적으로 사용자는 파드를 직접 만들 필요가 없다.
싱글톤이라도 대부분 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
컨트롤러는 클러스터 범위에서
복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
위와 같은 기능 제공을 할 수 있다.
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
@@ -165,7 +165,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.
1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
1. 파드의 컨테이너 중 하나에 [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자.
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
content/ko/docs/concepts/workloads/pods/podpreset.md
+1 -1
View File
@@ -17,7 +17,7 @@ weight: 50
`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
주입하기 위한 API 리소스이다.
주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드