kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #27374 from kubernetes/dev-1.20-ko.7 

[ko] Seventh Korean l10n work for release-1.20
This commit is contained in:
Kubernetes Prow Robot 2021-04-01 16:40:11 -07:00 committed by GitHub
parent 871e2ad8d6 2047c9bd7f
commit 029d2f6ed8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
54 changed files with 797 additions and 539 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -21,7 +21,7 @@ aliases:
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다.
`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.
컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.

46
content/ko/docs/concepts/architecture/nodes.md
View File

@ -27,7 +27,7 @@ weight: 10
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 노드를 추가하는 두가지 주요 방법이 있다.
1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
@ -48,8 +48,8 @@ weight: 10
쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
노드가 정상이면(필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될때까지 모든 클러스터 활동에
노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
대해 무시된다.
{{< note >}}
@ -226,13 +226,14 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
다음을 담당한다.
- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가
하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady
컨디션을 ConditionUnknown으로 업데이트 한다.
- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
#### 하트비트
@ -250,11 +251,12 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
`NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
보다 훨씬 길다).
주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초
보다 훨씬 길다.
- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
리스 업데이트는 `NodeStatus` 업데이트와는
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며
7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
#### 안정성
@ -264,13 +266,13 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.).
상태가 불량한 노드의 일부가 최소
`--unhealthy-zone-threshold` 기본값 0.55) 가
되면 축출 비율은 감소한다. 클러스터가 작으면 (즉
`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고,
그렇지 않으면 축출 비율은 초당
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
체크한다(NodeReady 컨디션은 ConditionUnknown 또는
ConditionFalse 다.).
- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold`
(기본값 0.55)가 되면 축출 비율은 감소한다.
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
@ -299,8 +301,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
### 노드 용량
노드 오브젝트는 노드 리소스 용량에 대한 정보(예: 사용 가능한 메모리의
양과 CPU의 수)를 추적한다.
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
양과 CPU의 수를 추적한다.
노드의 [자체 등록](#노드에-대한-자체-등록)은 등록하는 중에 용량을 보고한다.
[수동](#수동-노드-관리)으로 노드를 추가하는 경우 추가할 때
노드의 용량 정보를 설정해야 한다.

2
content/ko/docs/concepts/cluster-administration/manage-deployment.md
View File

@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
```shell
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml

4
content/ko/docs/concepts/configuration/configmap.md
View File

@ -42,8 +42,8 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
`binaryData` 는 모두 선택 사항이다. `data` 필드는
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
포함하도록 설계되었다.
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리
데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다.
컨피그맵의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

6
content/ko/docs/concepts/configuration/overview.md
View File

@ -81,9 +81,9 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_.
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
@ -96,7 +96,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
{{< /note >}}
{{< note >}}
기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
{{< /note >}}
## kubectl 사용하기

26
content/ko/docs/concepts/containers/images.md
View File

@ -49,16 +49,32 @@ weight: 10
## 이미지 업데이트
기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미
존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면,
다음 중 하나를 수행하면 된다.
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}},
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}, 파드 또는 파드
템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우
기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull)
정책은 `IfNotPresent`로 설정된다. 이 정책은
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는
이미지에 대한 풀을 생략하게 한다.
만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다.
- 컨테이너의 `imagePullPolicy`를 `Always`로 설정.
- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용.
- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용,
쿠버네티스는 정책을 `Always`로 설정한다.
- `imagePullPolicy`와 사용할 이미지의 태그를 생략.
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
{{< note >}}
컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
설정되고 나중에 이미지 태그가 변경되더라도 업데이트되지 않는다.
예를 들어, 태그가 `:latest`가 아닌 이미지로 디플로이먼트를 생성하고,
나중에 해당 디플로이먼트의 이미지를 `:latest` 태그로 업데이트하면
`imagePullPolicy` 필드가 `Always` 로 변경되지 않는다. 오브젝트를
처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다.
{{< /note >}}
`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
## 이미지 인덱스가 있는 다중 아키텍처 이미지

21
content/ko/docs/concepts/extend-kubernetes/operator.md
View File

@ -102,27 +102,28 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
## 자신만의 오퍼레이터 작성 {#writing-operator}
에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 직접 코딩할 수 있다.
[다음 내용](#다음-내용)에서는 클라우드 네이티브 오퍼레이터를 작성하는 데
사용할 수 있는 라이브러리 및 도구에 대한 몇 가지 링크를
찾을 수 있다.
에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면
직접 코딩할 수 있다.
또한 [쿠버네티스 API의 클라이언트](/ko/docs/reference/using-api/client-libraries/)
역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다.
다음은 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는
몇 가지 라이브러리와 도구들이다.
{{% thirdparty-content %}}
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
사용하여 직접 구현하기
* [오퍼레이터 프레임워크](https://operatorframework.io)
## {{% heading "whatsnext" %}}
* [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
* [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기
* 기존 도구를 사용하여 자신만의 오퍼레이터를 작성해보자. 다음은 예시이다.
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) 사용하기
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
사용하여 직접 구현하기
* [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
* 오퍼레이터 패턴을 소개한 [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) 읽기

2
content/ko/docs/concepts/overview/working-with-objects/annotations.md
View File

@ -37,7 +37,7 @@ weight: 50
자동 생성된 필드, 그리고
오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
* 빌드, 릴리스, 또는 타임 스탬프, 릴리즈 ID, git 브랜치,
* 빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치,
PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
* 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.

2
content/ko/docs/concepts/overview/working-with-objects/labels.md
View File

@ -32,7 +32,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.
레이블 예시:

2
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -5,7 +5,7 @@
title: 노드에 파드 할당하기
content_type: concept
weight: 50
weight: 20
---

2
content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
View File

@ -5,7 +5,7 @@
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
content_type: concept
weight: 50
weight: 30
---
<!-- overview -->

4
content/ko/docs/concepts/storage/dynamic-provisioning.md
View File

@ -75,8 +75,8 @@ parameters:
사용자는 `PersistentVolumeClaim` 에 스토리지 클래스를 포함시켜 동적으로 프로비전된
스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 `volume.beta.kubernetes.io/storage-class`
어노테이션을 통해 수행되었다. 그러나 이 어노테이션은
v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
`storageClassName` 필드를 사용할 수 있기에 대신하여 사용해야 한다. 이 필드의 값은
v1.9부터는 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의
`storageClassName` 필드를 사용해야 한다. 이 필드의 값은
관리자가 구성한 `StorageClass` 의 이름과
일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고)

3
content/ko/docs/concepts/storage/volumes.md
View File

@ -31,7 +31,8 @@ weight: 10
임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서
실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가
더 이상 존재하지 않으면, 볼륨은 삭제된다.
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는

6
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -51,8 +51,8 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
{{< note >}}
`.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며
값 배열은 "value"만 포함한다.
단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
`value` 배열은 "value"만 포함한다.
매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
{{< /note >}}
@ -1037,7 +1037,7 @@ echo $?
## 카나리 디플로이먼트
만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는
만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리스를 롤아웃 하기 위해서는
[리소스 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#카나리-canary-디플로이먼트)에
설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다.

2
content/ko/docs/contribute/new-content/open-a-pr.md
View File

@ -224,7 +224,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
{{% tab name="Hugo 컨테이너" %}}
{{< note >}}
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다.
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
{{< /note >}}
1. 로컬에서 이미지를 빌드한다.

22
content/ko/docs/reference/_index.md
View File

@ -6,6 +6,7 @@ linkTitle: "레퍼런스"
main_menu: true
weight: 70
content_type: concept
no_list: true
---
<!-- overview -->
@ -18,11 +19,17 @@ content_type: concept
## API 레퍼런스
* [표준 용어집](/ko/docs/reference/glossary/) - 포괄적이고, 표준화 된 쿠버네티스 용어 목록
* [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)
## API 클라이언트 라이브러리
## 공식적으로 지원되는 클라이언트 라이브러리
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
@ -32,22 +39,27 @@ content_type: concept
- [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
- [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
- [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
- [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell)
## CLI 레퍼런스
## CLI
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
## 컴포넌트 레퍼런스
## 컴포넌트
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
## 스케줄링
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
## 설계 문서

2
content/ko/docs/reference/access-authn-authz/_index.md
View File

@ -1,6 +1,6 @@
---
title: API 접근 제어
weight: 20
weight: 15
no_list: true
---

2
content/ko/docs/reference/command-line-tools-reference/_index.md
View File

@ -1,4 +1,4 @@
---
title: 커맨드 라인 도구 레퍼런스
title: 컴포넌트 도구
weight: 60
---

1
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -242,6 +242,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 |
| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |

103
content/ko/docs/reference/command-line-tools-reference/kube-proxy.md
View File

File diff suppressed because one or more lines are too long

2
content/ko/docs/reference/glossary/index.md
View File

@ -1,5 +1,5 @@
---
title: 표준 용어집
title: 용어집
layout: glossary
noedit: true
default_active_tag: fundamental

19
content/ko/docs/reference/glossary/volume-plugin.md Normal file
View File

@ -0,0 +1,19 @@
---
title: 볼륨 플러그인(Volume Plugin)
id: volumeplugin
date: 2018-04-12
full_link:
short_description: >
볼륨 플러그인은 파드 내에서의 스토리지 통합을 가능하게 한다.
aka:
tags:
- core-object
- storage
---
볼륨 플러그인은 {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 내에서의 스토리지 통합을 가능하게 한다.
<!--more-->
볼륨 플러그인을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 사용할 스토리지 볼륨을 연결하고 마운트할 수 있다. 볼륨 플러그인은 _인-트리(in tree)_ 혹은 _아웃-오브-트리(out of tree)_ 일 수 있다. _인-트리_ 플러그인은 쿠버네티스 코드 리포지터리의 일부이며 동일한 릴리즈 주기를 따른다. _아웃-오브-트리_ 플러그인은 독립적으로 개발된다.

2
content/ko/docs/reference/issues-security/_index.md
View File

@ -1,4 +1,4 @@
---
title: 쿠버네티스 이슈와 보안
weight: 10
weight: 40
---

2
content/ko/docs/reference/kubectl/_index.md
View File

@ -1,5 +1,5 @@
---
title: "kubectl CLI"
title: "kubectl"
weight: 60
---

2
content/ko/docs/reference/kubectl/overview.md
View File

@ -17,7 +17,7 @@ KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/c
이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다.
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고한다.
<!-- body -->

2
content/ko/docs/reference/scheduling/config.md
View File

@ -185,8 +185,6 @@ profiles:
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
익스텐션 포인트: `Score`.
- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다.
익스텐션 포인트: `PreScore`, `Score`.
- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지
확인한다.
익스텐션 포인트: `Filter`.

2
content/ko/docs/reference/setup-tools/_index.md
View File

@ -1,4 +1,4 @@
---
title: 설치 도구 레퍼런스
title: 설치 도구
weight: 50
---

18
content/ko/docs/reference/setup-tools/kubeadm/_index.md
View File

@ -16,15 +16,15 @@ kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데
## 설치 방법
kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다.
kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)를 참고한다.
## {{% heading "whatsnext" %}}
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다.
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다.
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다.
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다.
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다.
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다.
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다.
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다.
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다.
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다.
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.

6
content/ko/docs/reference/setup-tools/kubeadm/generated/_index.md Normal file
View File

@ -0,0 +1,6 @@
---
title: "Kubeadm Generated"
weight: 10
toc_hide: true
---

2
content/ko/docs/reference/tools.md → content/ko/docs/reference/tools/_index.md
View File

@ -16,7 +16,7 @@ content_type: concept
## Kubeadm
[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태).
[`kubeadm`](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태).
## Minikube

3
content/ko/docs/reference/using-api/_index.md
View File

@ -1,7 +1,8 @@
---
title: 쿠버네티스 API 개요
title: API 개요
content_type: concept
weight: 10
no_list: true
card:
name: 레퍼런스
weight: 50

2
content/ko/docs/setup/best-practices/multiple-zones.md
View File

@ -55,7 +55,7 @@ content_type: concept
특정 kubelet을 나타내는 노드 오브젝트에
{{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
이러한 레이블에는
[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
[영역 정보](/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과

355
content/ko/docs/setup/production-environment/container-runtimes.md
View File

@ -63,7 +63,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
### containerd
이 섹션에는 `containerd` 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
필수 구성 요소를 설치 및 구성한다.
@ -90,170 +90,63 @@ sudo sysctl --system
containerd를 설치한다.
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Ubuntu 16.04" %}}
{{% tab name="Linux" %}}
```shell
# 도커의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# (containerd 설치)
## 리포지터리 설정
### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
```shell
## 도커의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
```
2. containerd 설정
```shell
## 도커 apt 리포지터리 추가
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
## containerd 설치
sudo apt-get update && sudo apt-get install -y containerd.io
```
3. containerd 재시작
```shell
# containerd 구성
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
sudo systemctl restart containerd
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Ubuntu 18.04/20.04" %}}
```shell
# (containerd 설치)
sudo apt-get update && sudo apt-get install -y containerd
```
```shell
# containerd 구성
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Debian 9+" %}}
```shell
# (containerd 설치)
## 리포지터리 설정
### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
```shell
## 도커의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
```
```shell
## 도커 apt 리포지터리 추가
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"
```
```shell
## containerd 설치
sudo apt-get update && sudo apt-get install -y containerd.io
```
```shell
# 기본 containerd 구성 설정
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="CentOS/RHEL 7.4+" %}}
```shell
# (containerd 설치)
## 리포지터리 설정
### 필요한 패키지 설치
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
```
```shell
## 도커 리포지터리 추가
sudo yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
```shell
# containerd 설치
sudo yum update -y && sudo yum install -y containerd.io
```
```shell
## containerd 구성
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
<br />
Powershell 세션을 띄우고, `$Version` 환경 변수를 원하는 버전으로 설정(예: `$Version=1.4.3`)한 뒤, 다음 명령어를 실행한다.
<br />
PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다.
```powershell
# (containerd 설치)
# containerd 다운로드
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
```
1. containerd 다운로드
```powershell
# 추출 및 구성
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
```powershell
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
```
# 구성을 검토한다. 설정에 따라 조정할 수 있다.
# - sandbox_image (쿠버네티스 pause 이미지)
# - cni bin_dir 및 conf_dir locations
Get-Content config.toml
2. 추출과 설정
# (선택 사항이지만, 강력히 권장됨) containerd를 Windows Defender 검사 예외에 추가
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ```
```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다.
# - sandbox_image (쿠버네티스 일시중지 이미지)
# - cni bin 폴더와 conf 폴더 위치
Get-Content config.toml
# (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
```
3. containerd 실행
```powershell
.\containerd.exe --register-service
Start-Service containerd
```
```powershell
# containerd 시작
.\containerd.exe --register-service
Start-Service containerd
```
{{% /tab %}}
{{< /tabs >}}
#### systemd {#containerd-systemd}
#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd}
`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다.
@ -264,8 +157,14 @@ Start-Service containerd
SystemdCgroup = true
```
이 변경 사항을 적용하는 경우 containerd를 재시작한다.
```shell
sudo systemctl restart containerd
```
kubeadm을 사용하는 경우,
[kubelet용 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 수동으로 구성한다.
[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다.
### CRI-O
@ -453,138 +352,38 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
### 도커
각 노드에 도커 CE를 설치한다.
1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다.
쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는
도커 버전을 찾을 수 있다.
2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.
사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다.
```shell
sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
```
{{< tabs name="tab-cri-docker-installation" >}}
{{% tab name="Ubuntu 16.04+" %}}
{{< note >}}
`overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
{{< /note >}}
```shell
# (도커 CE 설치)
## 리포지터리 설정
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
sudo apt-get update && sudo apt-get install -y \
apt-transport-https ca-certificates curl software-properties-common gnupg2
```
3. 도커 재시작과 부팅시 실행되게 설정
```shell
# 도커 공식 GPG 키 추가:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
```
```shell
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker
```
```shell
# 도커 apt 리포지터리 추가:
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
# 도커 CE 설치
sudo apt-get update && sudo apt-get install -y \
containerd.io=1.2.13-2 \
docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
```
```shell
## /etc/docker 생성
sudo mkdir /etc/docker
```
```shell
# 도커 데몬 설정
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
EOF
```
```shell
# /etc/systemd/system/docker.service.d 생성
sudo mkdir -p /etc/systemd/system/docker.service.d
```
```shell
# 도커 재시작
sudo systemctl daemon-reload
sudo systemctl restart docker
```
{{% /tab %}}
{{% tab name="CentOS/RHEL 7.4+" %}}
```shell
# (도커 CE 설치)
## 리포지터리 설정
### 필요한 패키지 설치
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
```
```shell
## 도커 리포지터리 추가
sudo yum-config-manager --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
```shell
# 도커 CE 설치
sudo yum update -y && sudo yum install -y \
containerd.io-1.2.13 \
docker-ce-19.03.11 \
docker-ce-cli-19.03.11
```
```shell
## /etc/docker 생성
sudo mkdir /etc/docker
```
```shell
# 도커 데몬 설정
cat <<EOF | sudo tee /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
EOF
```
```shell
# /etc/systemd/system/docker.service.d 생성
sudo mkdir -p /etc/systemd/system/docker.service.d
```
```shell
# 도커 재시작
sudo systemctl daemon-reload
sudo systemctl restart docker
```
{{% /tab %}}
{{< /tabs >}}
부팅 시 `docker` 서비스를 시작하려면, 다음 명령을 실행한다.
```shell
sudo systemctl enable docker
```
자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/)를
참조한다.
{{< note >}}
더 자세한 내용은
- [도커 데몬 설정](https://docs.docker.com/config/daemon/)
- [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/)
{{< /note >}}

6
content/ko/docs/setup/production-environment/tools/kops.md
View File

@ -23,7 +23,7 @@ kops는 자동화된 프로비저닝 시스템인데,
## {{% heading "prerequisites" %}}
* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다.
* [kubectl](/ko/docs/tasks/tools/)을 반드시 설치해야 한다.
* 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다.
@ -44,7 +44,7 @@ kops는 자동화된 프로비저닝 시스템인데,
{{< tabs name="kops_installation" >}}
{{% tab name="macOS" %}}
최신 버전의 릴리즈를 다운받는 명령어:
최신 버전의 릴리스를 다운받는 명령어:
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest
@ -84,7 +84,7 @@ brew update && brew install kops
{{% /tab %}}
{{% tab name="리눅스" %}}
최신 릴리즈를 다운로드 받는 명령어:
최신 릴리스를 다운로드 받는 명령어:
```shell
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64

40
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -159,7 +159,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으
높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만,
그 반대의 경우는 아니다.
`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 참고한다.
{{< warning >}}
이 지침은 모든 시스템 업그레이드에서 모든 쿠버네티스 패키지를 제외한다.
@ -174,16 +174,34 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으
{{< tabs name="k8s_install" >}}
{{% 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 -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
1. `apt` 패키지 색인을 업데이트하고, 쿠버네티스 `apt` 리포지터리를 사용하는 데 필요한 패키지를 설치한다.
```shell
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
```
2. 구글 클라우드의 공개 사이닝 키를 다운로드 한다.
```shell
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
```
3. 쿠버네티스 `apt` 리포지터리를 추가한다.
```shell
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
4. `apt` 패키지 색인을 업데이트하고, kubelet, kubeadm, kubectl을 설치하고 해당 버전을 고정한다.
```shell
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```
{{% /tab %}}
{{% tab name="레드햇 기반 배포판" %}}
```bash

6
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -218,7 +218,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
#### IPv4/IPv6 이중 스택
`IPv6DualStack` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)을 참조한다.
`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 참조한다.
{{< note >}}
윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다.
@ -234,7 +234,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.
#### 컴퓨트
#### 컴퓨트 {#컴퓨트-제한}
##### 리소스 관리 및 프로세스 격리
@ -294,7 +294,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
* NFS 기반 스토리지/볼륨 지원
* 마운트된 볼륨 확장(resizefs)
#### 네트워킹
#### 네트워킹 {#네트워킹-제한}
윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다.

2
content/ko/docs/setup/release/notes.md
View File

@ -1906,7 +1906,7 @@ filename | sha512 hash
- Promote SupportNodePidsLimit to GA to provide node to pod pid isolation
Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing]
- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling]
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/&#35;transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing]
- Set CSIMigrationvSphere feature gates to beta.
Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver.

2
content/ko/docs/tasks/administer-cluster/access-cluster-api.md
View File

@ -193,7 +193,7 @@ func main() {
}
```
애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다.
애플리케이션이 클러스터 내의 파드로 배치된 경우, [파드 내에서 API 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#파드에서-api-접근)을 참고한다.
#### Python 클라이언트 {#python-client}

31
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
View File

@ -168,36 +168,7 @@ controllerManager:
### 인증서 서명 요청(CSR) 생성
`kubeadm certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.
```shell
sudo kubeadm certs renew apiserver --use-api &
```
출력 결과는 다음과 비슷하다.
```
[1] 2890
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
```
### 인증서 서명 요청(CSR) 승인
외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
```shell
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
```
출력 결과는 다음과 비슷하다.
```shell
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
```
`kubectl get csr` 명령으로 보류 중인 인증서 목록을 볼 수 있다.
쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다.
## 외부 CA로 인증서 갱신

2
content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
View File

@ -16,7 +16,7 @@ weight: 10
## {{% heading "prerequisites" %}}
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다.
[`kubectl`](/ko/docs/tasks/tools/)를 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

2
content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
View File

@ -12,7 +12,7 @@ weight: 30
## {{% heading "prerequisites" %}}
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

2
content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
View File

@ -13,7 +13,7 @@ weight: 40
## {{% heading "prerequisites" %}}
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

2
content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
## {{% heading "prerequisites" %}}
[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
[`kubectl`](/ko/docs/tasks/tools/)을 설치한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

226
content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md Normal file
View File

@ -0,0 +1,226 @@
---
title: 클러스터에서 TLS 인증서 관리
content_type: task
---
<!-- overview -->
쿠버네티스는 사용자가 제어하는 ​​인증 기관 (CA)에서 서명한 TLS 인증서를
프로비저닝 할 수 있는 `certificates.k8s.io` API를 제공한다.
이러한 CA 및 인증서는 워크로드 간의 신뢰 관계를 구성하는 용도로 사용할 수 있다.
`certificates.k8s.io` API는 [ACME 초안](https://github.com/ietf-wg-acme/acme/)과
유사한 프로토콜을 사용한다.
{{< note >}}
`certificates.k8s.io` API를 사용하여 생성된 인증서는 전용 CA로 서명된다.
이러한 목적을 위해 클러스터 루트 CA를 사용하도록 클러스터를
구성할 수 있지만, 절대 이에 의존해서는 안된다.
해당 인증서가 클러스터 루트 CA에 대해 유효성을 검사한다고 가정하면 안된다.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 클러스터에서 TLS 신뢰
파드로 실행되는 애플리케이션에서 사용자 정의 CA를 신뢰하려면
일반적으로 몇 가지 추가 애플리케이션 구성이 필요하다.
TLS 클라이언트 또는 서버가 신뢰하는 CA 인증서 목록에
CA 인증서 번들을 추가해야 한다.
예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://godoc.org/crypto/tls#Config) 구조체의
`RootCAs` 필드에 추가하여, golang TLS 구성으로 이를 수행할 수 있다.
CA 인증서를 파드에서 사용할 수 있는
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap)으로
배포할 수 있다.
## 인증서 요청
다음 섹션에서는 DNS를 통해 액세스되는 쿠버네티스 서비스의
TLS 인증서를 생성하는 방법을 보여준다.
{{< note >}}
이 튜토리얼에서는 CFSSL을 사용한다. [여기를 클릭](https://blog.cloudflare.com/introducing-cfssl/)하여 Cloudflare의 PKI 및 TLS 툴킷을 자세히 알아본다.
{{< /note >}}
## CFSSL 다운로드 및 설치
이 예제에 사용된 cfssl 도구는
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 다운로드 할 수 있다.
## 인증서 서명 요청 (CSR) 생성
다음 명령을 실행하여 개인 키 및 인증서 서명 요청(또는 CSR)을
생성한다.
```shell
cat <<EOF | cfssl genkey - | cfssljson -bare server
{
"hosts": [
"my-svc.my-namespace.svc.cluster.local",
"my-pod.my-namespace.pod.cluster.local",
"192.0.2.24",
"10.0.34.2"
],
"CN": "system:node:my-pod.my-namespace.pod.cluster.local",
"key": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"O": "system:nodes"
}
]
}
EOF
```
여기서 `192.0.2.24`는 서비스의 클러스터 IP,
`my-svc.my-namespace.svc.cluster.local`은 서비스의 DNS 이름,
`10.0.34.2`는 파드의 IP,`my-pod.my- namespace.pod.cluster.local`은
파드의 DNS 이름이다. 다음 출력이 표시되어야 한다.
```
2017/03/21 06:48:17 [INFO] generate received request
2017/03/21 06:48:17 [INFO] received CSR
2017/03/21 06:48:17 [INFO] generating key: ecdsa-256
2017/03/21 06:48:17 [INFO] encoded CSR
```
이 명령은 두 개의 파일을 생성한다. PEM으로
인코딩된 [pkcs#10](https://tools.ietf.org/html/rfc2986)
인증 요청이 포함된 `server.csr`과 생성할 인증서 키를 PEM 인코딩한 값이
포함된 `server-key.pem`을 생성한다.
## 쿠버네티스 API로 보낼 인증서 서명 요청 객체 만들기
CSR yaml blob을 생성하고 다음 명령을 실행하여
apiserver로 보낸다.
```shell
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: my-svc.my-namespace
spec:
request: $(cat server.csr | base64 | tr -d '\n')
signerName: kubernetes.io/kubelet-serving
usages:
- digital signature
- key encipherment
- server auth
EOF
```
1단계에서 만든 `server.csr` 파일은 base64로 인코딩되고
`.spec.request` 필드에 숨겨져 있다.
또한 `kubernetes.io/kubelet-serving` 서명자가 서명한
"digitalSignature", "keyEnciperment" 및 "serverAuth" 키 사용(keyUsage)이 있는 인증서를 요청한다.
특정 `signerName`을 요청해야 한다.
자세한 내용은 [지원되는 서명자 이름](/docs/reference/access-authn-authz/certificate-signing-requests/#signers)
문서를 참조한다.
이제 CSR이 API에서 보류 상태로 표시되어야 한다. 다음을 실행하여
확인할 수 있다.
```shell
kubectl describe csr my-svc.my-namespace
```
```none
Name: my-svc.my-namespace
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700
Requesting User: yourname@example.com
Status: Pending
Subject:
Common Name: my-svc.my-namespace.svc.cluster.local
Serial Number:
Subject Alternative Names:
DNS Names: my-svc.my-namespace.svc.cluster.local
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
```
## 인증서 서명 요청 승인 받기
인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나
클러스터 관리자에 의해 일회성으로 수행한다. 여기에
관련된 내용에 대한 자세한 내용은 아래에서 설명한다.
## 인증서 다운로드 및 사용
CSR이 서명되고 승인되면 다음이 표시된다.
```shell
kubectl get csr
```
```none
NAME AGE REQUESTOR CONDITION
my-svc.my-namespace 10m yourname@example.com Approved,Issued
```
다음을 실행하여 발급된 인증서를 다운로드하고 `server.crt` 파일에
저장할 수 있다.
```shell
kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
```
이제 `server.crt` 및 `server-key.pem`을 키페어(keypair)로 사용하여
HTTPS 서버를 시작할 수 있다.
## 인증서 서명 요청 승인
(적절한 권한이 있는) 쿠버네티스 관리자는
`kubectl certificate approve` 과 `kubectl certificate deny`
명령을 사용하여 인증서 서명 요청을 수동으로 승인 (또는 거부) 할 수 있다.
그러나 이 API를 많이 사용한다면,
자동화된 인증서 컨트롤러 작성을 고려할 수 있다.
위와 같이 kubectl을 사용하는 시스템이든 사람이든, 승인자의 역할은
CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다.
1. CSR은 CSR에 서명하는 데 사용되는 개인 키를 제어하는 것이다. 이는
승인된 대상으로 가장하는 제 3자의 위협을 해결한다. 위의 예에서
이 단계는 파드(pod)가 CSR을 생성하는 데
사용되는 개인 키를 제어하는지 확인하는 것이다.
2. CSR은 요청된 상황에서 작동할 권한이 있다. 이것은
원하지 않는 대상이 클러스터에 합류(join)하는 위협을
해결한다. 위의 예에서, 이 단계는
파드가 요청된 서비스에 참여할 수 있는지 확인하는 것이다.
이 두 가지 요구 사항이 충족되는 경우에만, 승인자가 CSR을 승인하고
그렇지 않으면 CSR을 거부해야 한다.
## 승인 허가에 대한 경고문
CSR을 승인하는 능력은 환경 내에서 누구를 신뢰하는지 결정한다. CSR 승인
능력은 광범위하거나 가볍게 부여해서는 안된다. 이 권한을
부여하기 전에 이전 섹션에서 언급한
요청의 요구 사항과 특정 인증서 발급의 영향을
완전히 이해해야 한다.
## 클러스터 관리자를 위한 참고 사항
이 가이드에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스
컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를
활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와
`--cluster-signing-key-file` 매개 변수를
컨트롤러 관리자에 전달한다.

4
content/ko/docs/tasks/tools/_index.md
View File

@ -53,7 +53,7 @@ kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준
{{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 도구를 사용하여 쿠버네티스 클러스터를 만들고 관리할 수 있다.
사용자 친화적인 방식으로 최소한의 실행 가능하고 안전한 클러스터를 설정하고 실행하는 데 필요한 작업을 수행한다.
[kubeadm 설치](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다.
[kubeadm 설치](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다.
설치가 끝나면, [클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)이 가능하다.
<a class="btn btn-primary" href="/docs/setup/production-environment/tools/kubeadm/install-kubeadm/" role="button" aria-label="kubeadm 설치 가이드 보기">kubeadm 설치 가이드 보기</a>
<a class="btn btn-primary" href="/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/" role="button" aria-label="kubeadm 설치 가이드 보기">kubeadm 설치 가이드 보기</a>

53
content/ko/docs/tasks/tools/install-kubectl-linux.md
View File

@ -20,10 +20,16 @@ card:
다음과 같은 방법으로 리눅스에 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)
- [{{% heading "prerequisites" %}}](#시작하기-전에)
- [리눅스에 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}
- [kubectl 구성 확인](#kubectl-구성-확인)
- [선택적 kubectl 구성](#선택적-kubectl-구성)
- [셸 자동 완성 활성화](#셸-자동-완성-활성화)
- [{{% heading "whatsnext" %}}](#다음-내용)
### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-linux}
@ -100,15 +106,38 @@ card:
### 기본 패키지 관리 도구를 사용하여 설치 {#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="데비안 기반의 배포판" %}}
{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
1. `apt` 패키지 색인을 업데이트하고 쿠버네티스 `apt` 리포지터리를 사용하는 데 필요한 패키지들을 설치한다.
```shell
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
```
2. 구글 클라우드 공개 사이닝 키를 다운로드한다.
```shell
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
```
3. 쿠버네티스 `apt` 리포지터리를 추가한다.
```shell
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
4. 새 리포지터리의 `apt` 패키지 색인을 업데이트하고 kubectl을 설치한다.
```shell
sudo apt-get update
sudo apt-get install -y kubectl
```
{{% /tab %}}
{{< tab name="레드햇 기반의 배포판" 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

4
content/ko/docs/tasks/tools/install-kubectl-macos.md
View File

@ -23,7 +23,7 @@ card:
- [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에서 Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk)
### macOS에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-macos}
@ -157,4 +157,4 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
## {{% heading "whatsnext" %}}
{{< include "included/kubectl-whats-next.md" >}}
{{< include "included/kubectl-whats-next.md" >}}

4
content/ko/docs/tutorials/clusters/apparmor.md
View File

@ -103,7 +103,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한
AppArmor 지원이 포함된 Kubelet (>= v1.4)이면
어떤 전제 조건이 충족되지 않으면 AppArmor와 함께한 파드를 거부한다.
노드 상에 AppArmor 지원 여부는
노드 준비 조건 메시지를 확인하여(이후 릴리즈에서는 삭제될 것 같지만) 검증할 수 있다.
노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다.
```shell
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
@ -396,7 +396,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다.
모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니
전환이 필요할 때에 상세히 설명할 것이다.
최소 두 번의 릴리즈에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
그 이후부터는 어노테이션은 명확히 거부된다.
## 프로파일 제작 {#authoring-profiles}

251
content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
View File

@ -1,22 +1,23 @@
---
title: 컨피그 맵을 사용해서 Redis 설정하기
title: 컨피그맵을 사용해서 Redis 설정하기
content_type: tutorial
---
<!-- overview -->
이 페이지에서는 컨피그 맵을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다.
이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다.
## {{% heading "objectives" %}}
* 다음을 포함하는 `kustomization.yaml` 파일을 생성한다.
* 컨피그 맵 생성자
* 컨피그 맵을 사용하는 파드 리소스
* `kubectl apply -k ./`를 실행하여 작업한 디렉터리를 적용한다.
* 구성이 잘 적용되었는지 확인한다.
* Redis 설정값으로 컨피그맵을 생성한다.
* 생성된 컨피그맵을 마운트하고 사용하는 Redis 파드를 생성한다.
* 설정이 잘 적용되었는지 확인한다.
@ -26,91 +27,227 @@ content_type: tutorial
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* 예시는 `kubectl` 1.14 이상 버전에서 동작한다.
* [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
* [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
<!-- lessoncontent -->
## 실세상 예제: 컨피그 맵을 사용해서 Redis 설정하기
## 실세상 예제: 컨피그맵을 사용해서 Redis 설정하기
아래의 단계를 통해서 컨피그 맵에 저장된 데이터를 사용해서 Redis 캐시를 설정할 수 있다.
아래 단계를 통해서, 컨피그맵에 저장된 데이터를 사용하는 Redis 캐시를 설정한다.
첫째, `redis-config` 파일에서 컨피그 맵을 포함한 `kustomization.yaml`를 생성한다.
{{< codenew file="pods/config/redis-config" >}}
우선, 비어 있는 설정으로 컨피그맵을 생성한다.
```shell
curl -OL https://k8s.io/examples/pods/config/redis-config
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: example-redis-config
files:
- redis-config
cat <<EOF >./example-redis-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: example-redis-config
data:
redis-config: ""
EOF
```
`kustomization.yaml`에 파드 리소스 구성을 추가한다.
위에서 생성한 컨피그맵을 Redis 파드 매니페스트와 함께 적용한다.
```shell
kubectl apply -f example-redis-config.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
```
Redis 파드 매니페스트의 내용을 검토하고 다음의 사항을 염두에 둔다.
* `config` 라는 이름의 볼륨은 `spec.volumes[1]` 에 의해서 생성된다.
* `spec.volumes[1].items[0]` 내부의 `key` 와 `path` 는 `config` 볼륨에 `redis.conf` 라는 파일명으로 지정된
`example-redis-config` 컨피그맵의 `redis-config` 키를 노출시킨다.
* 그리고 `config` 볼륨은 `spec.containers[0].volumeMounts[1]` 에 의해서 `/redis-master` 에 마운트된다.
이 내용은 위의 `example-redis-config` 컨피그맵의 `data.redis-config` 내부 데이터를 파드 안에 있는
`/redis-master/redis.conf` 파일의 내용으로 노출시키는 순효과(net effect)를 낸다.
{{< codenew file="pods/config/redis-pod.yaml" >}}
```shell
curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
cat <<EOF >>./kustomization.yaml
resources:
- redis-pod.yaml
EOF
```
컨피그 맵과 파드 오브젝트를 생성하도록 kustomization 디렉터리를 적용한다.
```shell
kubectl apply -k .
```
생성된 오브젝트를 확인한다.
```shell
> kubectl get -k .
NAME DATA AGE
configmap/example-redis-config-dgh9dg555m 1 52s
NAME READY STATUS RESTARTS AGE
pod/redis 1/1 Running 0 52s
```shell
kubectl get pod/redis configmap/example-redis-config
```
이 예제에서는 설정 볼륨이 `/redis-master`에 마운트되어 있다.
`redis-config` 키를 `redis.conf`라는 이름의 파일에 추가하기 위해 `path`를 사용한다.
따라서, Redis 설정을 위한 파일 경로는 `/redis-master/redis.conf`이다.
이곳이 이미지가 Redis 마스터를 위한 설정 파일을 찾는 곳이다.
다음의 결과를 볼 수 있다.
설정이 올바르게 적용되었는지 확인하기 위해서,
`kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다.
```shell
NAME READY STATUS RESTARTS AGE
pod/redis 1/1 Running 0 8s
NAME DATA AGE
configmap/example-redis-config 1 14s
```
`example-redis-config` 컨피그맵의 `redis-config` 키를 공란으로 둔 것을 기억하자.
```shell
kubectl describe configmap/example-redis-config
```
`redis-config` 키가 비어 있는 것을 확인할 수 있다.
```shell
Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
```
`kubectl exec` 를 사용하여 파드에 접속하고, 현재 설정 확인을 위해서 `redis-cli` 도구를 실행한다.
```shell
kubectl exec -it redis -- redis-cli
```
`maxmemory` 를 확인한다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory
```
기본값인 0을 볼 수 있을 것이다.
```shell
1) "maxmemory"
2) "0"
```
유사하게, `maxmemory-policy` 를 확인한다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory-policy
```
이것도 기본값인 `noeviction` 을 보여줄 것이다.
```shell
1) "maxmemory-policy"
2) "noeviction"
```
이제 `example-redis-config` 컨피그맵에 몇 가지 설정값을 추가해 본다.
{{< codenew file="pods/config/example-redis-config.yaml" >}}
갱신된 컨피그맵을 적용한다.
```shell
kubectl apply -f example-redis-config.yaml
```
컨피그맵이 갱신된 것을 확인한다.
```shell
kubectl describe configmap/example-redis-config
```
방금 추가한 설정값을 확인할 수 있을 것이다.
```shell
Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru
```
설정이 적용되었는지 확인하려면, `kubectl exec` 를 통한 `redis-cli` 로 Redis 파드를 다시 확인한다.
```shell
kubectl exec -it redis -- redis-cli
```
`maxmemory` 를 확인한다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory
```
기본값인 0을 볼 수 있을 것이다.
```shell
1) "maxmemory"
2) "0"
```
유사하게, `maxmemory-policy` 도 기본 설정인 `noeviction` 을 보여줄 것이다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory-policy
```
위의 명령은 다음을 반환한다.
```shell
1) "maxmemory-policy"
2) "noeviction"
```
파드는 연관된 컨피그맵에서 갱신된 값을 인지하기 위해서 재시작이 필요하므로
해당 설정값이 변경되지 않은 상태이다. 파드를 삭제하고 다시 생성한다.
```shell
kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
```
이제 마지막으로 설정값을 다시 확인해 본다.
```shell
kubectl exec -it redis -- redis-cli
```
`maxmemory` 를 확인한다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory
```
이것은 이제 갱신된 값인 2097152를 반환한다.
```shell
1) "maxmemory"
2) "2097152"
```
유사하게, `maxmemory-policy` 도 갱신되어 있다.
```shell
127.0.0.1:6379> CONFIG GET maxmemory-policy
```
이것은 원하는 값인 `allkeys-lru` 를 반환한다.
```shell
1) "maxmemory-policy"
2) "allkeys-lru"
```
생성된 파드를 삭제한다.
생성된 자원을 삭제하여 작업을 정리한다.
```shell
kubectl delete pod redis
kubectl delete pod/redis configmap/example-redis-config
```
## {{% heading "whatsnext" %}}
* [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 배우기.
* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 배우기.

2
content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
View File

@ -37,7 +37,7 @@ weight: 10
<li><i>ClusterIP</i> (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.</li>
<li><i>NodePort</i> - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.</li>
<li><i>LoadBalancer</i> - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다. </li>
<li><i>ExternalName</i> - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 <code>externalName</code>으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 <code>kube-dns</code> 버전 1.7 이상에서 지원 가능하다.</li>
<li><i>ExternalName</i> - <code>CNAME</code> 레코드 및 값을 반환함으로써 서비스를 <code>externalName</code> 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 <code>kube-dns</code> v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.</li>
</ul>
<p>다른 서비스 타입들에 대한 추가 정보는 <a href="/ko/docs/tutorials/services/source-ip/">소스 IP 이용하기</a> 튜토리얼에서 확인 가능하다. 또한 <a href="/docs/concepts/services-networking/connect-applications-service">서비스들로 애플리케이션에 접속하기</a>도 참고해 보자.</p>
<p>부가적으로, spec에 <code>selector</code>를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. <code>selector</code> 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 <code>type: ExternalName</code>을 이용하겠다고 확고하게 의도하는 경우이다.</p>

2
content/ko/docs/tutorials/stateful-application/cassandra.md
View File

@ -270,7 +270,7 @@ kubectl apply -f cassandra-statefulset.yaml
기반하였고 OpenJDK 8을 포함한다.
이 이미지는 아파치 데비안 리포의 표준 카산드라 설치본을 포함한다.
환경변수를 이용하여 `cassandra.yaml`에 삽입된 값을 바꿀 수 있다.
환경 변수를 이용하여 `cassandra.yaml`에 삽입된 값을 바꿀 수 있다.
| 환경 변수 | 기본값 |
| ------------- |:-------------: |

2
content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
View File

@ -11,7 +11,7 @@ weight: 10
## {{% heading "prerequisites" %}}
* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.
* [kubectl](/ko/docs/tasks/tools/)을 설치한다.
* Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여
쿠버네티스 클러스터를 생성한다. 이 튜토리얼은
[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,

8
content/ko/docs/tutorials/stateless-application/guestbook.md
View File

@ -1,5 +1,7 @@
---
title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기"
content_type: tutorial
weight: 20
card:
@ -15,8 +17,6 @@ min-kubernetes-server-version: v1.14
* 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/)
* 여러 개의 웹 프론트엔드 인스턴스
## {{% heading "objectives" %}}
* Mongo 데이터베이스를 시작
@ -87,6 +87,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.ya
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
```
<!--
컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
@ -103,7 +104,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
mongo ClusterIP 10.0.0.151 <none> 6379/TCP 8s
mongo ClusterIP 10.0.0.151 <none> 27017/TCP 8s
```
{{< note >}}
@ -289,7 +290,6 @@ kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.ya
deployment.apps "mongo" deleted
service "mongo" deleted
deployment.apps "frontend" deleted
deployment.apps "frontend" deleted
service "frontend" deleted
```

8
content/ko/examples/pods/config/example-redis-config.yaml Normal file
View File

@ -0,0 +1,8 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: example-redis-config
data:
redis-config: |
maxmemory 2mb
maxmemory-policy allkeys-lru