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

Merge pull request #30412 from kubernetes/dev-1.22-ko.2 

[ko] 2nd Korean localization work for v1.22
pull/30421/head
Kubernetes Prow Robot 2021-11-09 05:39:47 -08:00 committed by GitHub
parent 0e19aed5dc 7d7d0224f7
commit b81dcba911
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
82 changed files with 2255 additions and 503 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md
View File

@ -142,7 +142,7 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에
# 다가오는 릴리스 웨비나
이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 9월 7일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요.
이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 10월 5일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요.
# 참여하기

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

@ -122,6 +122,9 @@ kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
kubectl cordon $NODENAME
```
보다 자세한 내용은 [안전하게 노드를 드레인(drain)하기](/docs/tasks/administer-cluster/safely-drain-node/)
를 참고한다.
{{< note >}}
{{< glossary_tooltip term_id="daemonset" >}}에 포함되는 일부 파드는
스케줄 불가 노드에서 실행될 수 있다. 일반적으로 데몬셋은 워크로드 애플리케이션을
@ -174,7 +177,7 @@ kubectl describe node <insert-node-name-here>
대신 코드화된 노드는 사양에 스케줄 불가로 표시된다.
{{< /note >}}
노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다.
쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.
```json
"conditions": [
@ -189,20 +192,30 @@ kubectl describe node <insert-node-name-here>
]
```
ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
ready 컨디션의 `status`가 `pod-eviction-timeout`
({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager"
>}}에 전달된 인수)보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우,
[노드 컨트롤러](#node-controller)가 해당 노드에 할당된 전체 파드에 대해
{{< glossary_tooltip text="API를 이용한 축출" term_id="api-eviction" >}}
을 트리거한다. 기본 축출 타임아웃 기간은
**5분** 이다.
노드에 접근이 불가할 때와 같은 경우, API 서버는 노드 상의 kubelet과 통신이 불가하다.
API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다.
그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를
강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서
노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다.
파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는
[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록
{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다.
자세한 내용은
[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다.
@ -222,8 +235,34 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
### 정보
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다.
이 정보는 Kubelet에 의해 노드로부터 수집된다.
커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다.
이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다.
## 하트비트
쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를
판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다.
노드에는 두 가지 형태의 하트비트가 있다.
* 노드의 `.status`에 대한 업데이트
* `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트.
각 노드는 연관된 리스 오브젝트를 갖는다.
노드의 `.status`와 비교해서, 리스는 경량의 리소스이다.
큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다.
kubelet은 노드의 `.status` 생성과 업데이트 및
관련된 리스의 업데이트를 담당한다.
- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다.
노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다.
- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다.
리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다.
만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
### 노드 컨트롤러
@ -241,39 +280,15 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
다음을 담당한다.
- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가
하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady
컨디션을 ConditionUnknown으로 업데이트 한다.
- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다.
ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
파드를 축출하기 시작하는 값은 5분이다.
- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다.
기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
#### 하트비트
쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
하트비트의 두 가지 형태는 `NodeStatus` 와
[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)이다.
각 노드에는 `kube-node-lease` 라는
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다.
리스는 경량 리소스로, 클러스터가 확장될 때
노드의 하트비트 성능을 향상 시킨다.
kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
의무가 있다.
- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
`NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초
보다 훨씬 길다.
- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
리스 업데이트는 `NodeStatus` 업데이트와는
독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며
7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다.
#### 안정성
#### 축출 빈도 한계
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여
@ -281,8 +296,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
체크한다(NodeReady 컨디션은 ConditionUnknown 또는
ConditionFalse 다).
체크한다(NodeReady 컨디션은 `ConditionUnknown` 또는
`ConditionFalse` 다).
- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold`
(기본값 0.55)가 되면 축출 속도가 감소한다.
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
@ -292,16 +307,15 @@ ConditionFalse 다).
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면,
오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상,
축출 매커니즘은 영역 별 가용성을 고려하지 않는다.
노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
`--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이
완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다.
이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.)
또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의
노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다.
@ -309,7 +323,7 @@ ConditionFalse 다).
{{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
### 노드 용량
## 리소스 용량 추적 {#node-capacity}
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
양과 CPU의 수를 추적한다.

8
content/ko/docs/concepts/cluster-administration/logging.md
View File

@ -17,8 +17,8 @@ weight: 60
<!-- body -->
클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는
로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만,
클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가
로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만,
쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다.
## 쿠버네티스의 기본 로깅
@ -136,7 +136,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다.
로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는
로깅 에이전트는 모든 노드에서 실행되어야 하므로, 에이전트를
`DaemonSet` 으로 동작시키는 것을 추천한다.
노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다.
@ -262,4 +262,4 @@ fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](http
![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png)
모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다.
애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다.

25
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -1,4 +1,6 @@
---
title: 클러스터 네트워킹
content_type: concept
weight: 50
@ -89,18 +91,6 @@ VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모
프로젝트 [Antrea](https://github.com/vmware-tanzu/antrea)는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다.
Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다.
### Apstra의 AOS
[AOS](https://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다.
AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다.
AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수 있는 풍부한 REST API 엔드포인트 셋을 제공한다. 네트워크 설계에 사용된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 클라우드와 퍼블릭 클라우드 모두에 대한 엔드-투-엔드 관리 시스템을 향상시킬 수 있다.
AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다.
AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. https://www.apstra.com/products/how-it-works/
### 쿠버네티스용 AWS VPC CNI
[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다.
@ -114,15 +104,6 @@ AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다
Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)에서 기본적으로 사용할 수 있다.
### Big Switch Networks의 빅 클라우드 패브릭(Big Cloud Fabric)
[빅 클라우드 패브릭](https://www.bigswitch.com/container-network-automation)은 클라우드 네이티브 네트워킹 아키텍처로, 프라이빗 클라우드/온-프레미스 환경에서 쿠버네티스를 실행하도록 디자인되었다. 통합된 물리 및 가상 SDN을 사용하여, 빅 클라우드 패브릭은 로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 내재한 컨테이너 네트워킹 문제를 해결한다.
빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다.
가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다.
### 캘리코
[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
@ -267,7 +248,7 @@ Lars Kellogg-Stedman이 제공하는
[Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다.
Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다.
Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다.
### OVN4NFV-K8s-Plugin (OVN 기반의 CNI 컨트롤러 & 플러그인)

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

@ -61,6 +61,11 @@ v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여
기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은
동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 있어야 한다.
{{< note >}}
{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵
또는 다른 API 오브젝트를 참조할 수 없다.
{{< /note >}}
다음은 단일 값을 가진 키와,
값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의
예시이다.

13
content/ko/docs/concepts/configuration/manage-resources-containers.md
View File

@ -182,8 +182,8 @@ kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을
플래그의 값으로 사용된다.
- 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고
100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 총 CPU
시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다.
100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 마이크로초 단위의
총 CPU 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다.
{{< note >}}
기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다.
@ -338,6 +338,9 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
@ -345,6 +348,12 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
volumes:
- name: ephemeral
emptyDir: {}
```
### 임시-스토리지 요청이 있는 파드의 스케줄링 방법

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

@ -73,32 +73,6 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
## 컨테이너 이미지
[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다.
- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_.
- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_.
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
{{< note >}}
컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
{{< /note >}}
{{< note >}}
운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다.
{{< /note >}}
{{< note >}}
레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다.
{{< /note >}}
## kubectl 사용하기
- `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.

31
content/ko/docs/concepts/configuration/secret.md
View File

@ -77,7 +77,7 @@ weight: 30
시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의
유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다.
시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다.
시크릿 타입은 여러 종류의 기밀 데이터를 프로그래밍 방식으로 용이하게 처리하기 위해 사용된다.
쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다.
이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에
@ -212,7 +212,8 @@ data:
kubectl create secret docker-registry secret-tiger-docker \
--docker-username=tiger \
--docker-password=pass113 \
--docker-email=tiger@acme.com
--docker-email=tiger@acme.com \
--docker-server=my-registry.example:5000
```
이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다.
@ -222,15 +223,21 @@ kubectl create secret docker-registry secret-tiger-docker \
```json
{
"auths": {
"https://index.docker.io/v1/": {
"username": "tiger",
"password": "pass113",
"email": "tiger@acme.com",
"auth": "dGlnZXI6cGFzczExMw=="
}
}
"apiVersion": "v1",
"data": {
".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ=="
},
"kind": "Secret",
"metadata": {
"creationTimestamp": "2021-07-01T07:30:59Z",
"name": "secret-tiger-docker",
"namespace": "default",
"resourceVersion": "566718",
"uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca"
},
"type": "kubernetes.io/dockerconfigjson"
}
```
### 기본 인증 시크릿
@ -834,6 +841,9 @@ kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한
파드가 포함된다. kubelet의 `--manifest-url` 플래그, `--config` 플래그 또는
kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로
생성된 파드는 포함하지 않는다.
{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵
또는 다른 API 오브젝트를 참조할 수 없다.
시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경
변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을
@ -1252,3 +1262,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
- [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기

2
content/ko/docs/concepts/containers/container-environment.md
View File

@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.

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

@ -39,14 +39,6 @@ weight: 10
배치할 수 있는 위치에 대한 추가 규칙이 있다.
태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다.
{{< caution >}}
프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다.
실행 중인 이미지 버전을 추적하기가 어렵고
이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다.
대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다.
{{< /caution >}}
## 이미지 업데이트
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}},
@ -57,13 +49,62 @@ weight: 10
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는
이미지에 대한 풀을 생략하게 한다.
만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다.
### 이미지 풀(pull) 정책
- 컨테이너의 `imagePullPolicy`를 `Always`로 설정.
- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용,
쿠버네티스는 정책을 `Always`로 설정한다.
- `imagePullPolicy`와 사용할 이미지의 태그를 생략.
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는
[kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다.
다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다.
`IfNotPresent`
: 이미지가 로컬에 없는 경우에만 내려받는다.
`Always`
: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의
[다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다.
일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다.
이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서
컨테이너를 기동할 때 사용한다.
`Never`
: kubelet은 이미지를 가져오려고 시도하지 않는다. 이미지가 어쨌든 이미 로컬에 존재하는
경우, kubelet은 컨테이너 기동을 시도한다. 이외의 경우 기동은 실패한다.
보다 자세한 내용은 [미리 내려받은 이미지](#pre-pulled-images)를 참조한다.
이미지 제공자에 앞서 깔린 캐시의 의미 체계는 레지스트리에 안정적으로 접근할 수 있는 한,
`imagePullPolicy: Always`인 경우 조차도 효율적이다.
컨테이너 런타임은 노드에 이미 존재하는 이미지 레이어를 알고
다시 내려받지 않는다.
{{< note >}}
프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데,
이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다.
대신, `v1.42.0`과 같이 의미있는 태그를 명기한다.
{{< /note >}}
파드가 항상 컨테이너 이미지의 같은 버전을 사용하는 것을 확실히 하려면,
이미지의 다이제스트를 명기할 수 있다.
`<image-name>:<tag>`를 `<image-name>@<digest>`로 교체한다.
(예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.
파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다.
이는 레지스트리에서 태그가 변경되는 일이 발생해도
구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다.
#### 기본 이미지 풀 정책 {#imagepullpolicy-defaulting}
사용자(또는 컨트롤러)가 신규 파드를 API 서버에 요청할 때,
특정 조건에 부합하면 클러스터가 `imagePullPolicy` 필드를 설정한다.
- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그가
`:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다.
- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우,
`imagePullPolicy`는 자동으로 `Always`로 설정된다.
- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다.
{{< note >}}
컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
@ -75,7 +116,16 @@ weight: 10
처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다.
{{< /note >}}
`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
#### 이미지 풀 강제
이미지를 내려받도록 강제하려면, 다음 중 한가지 방법을 사용한다.
- 컨테이너의 `imagePullPolicy`를 `Always`로 설정한다.
- `imagePullPolicy`를 생략하고 사용할 이미지 태그로 `:latest`를 사용한다.
그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
- `imagePullPolicy`와 사용할 이미지의 태그를 생략한다.
그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다.
### 이미지풀백오프(ImagePullBackOff)
@ -208,7 +258,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
### 미리 내려받은 이미지
### 미리 내려받은 이미지 {#pre-pulled-images}
{{< note >}}
이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
@ -328,6 +378,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다.
## {{% heading "whatsnext" %}}
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.

9
content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -1,5 +1,5 @@
---
title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기
title: 쿠버네티스 API 애그리게이션 레이어(aggregation layer)
@ -11,7 +11,7 @@ weight: 10
<!-- overview -->
애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다.
추가 API는 [서비스-카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다.
애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다.
@ -34,5 +34,6 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
* 다음에, [확장 API 서버를 구성해서](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
* [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다.
* API 레퍼런스에서 [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)에 대해 읽어본다.
대안으로, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.

11
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -35,11 +35,10 @@ weight: 10
커스텀 리소스를 *커스텀 컨트롤러* 와 결합하면, 커스텀 리소스가 진정한
_선언적(declarative) API_ 를 제공하게 된다.
[선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 리소스의 의도한 상태를
_선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트의 현재 상태를 의도한 상태와
동기화 상태로 유지하려고 한다. 컨트롤러는 구조화된 데이터를 사용자가
원하는 상태의 레코드로 해석하고 지속적으로
이 상태를 유지한다.
쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는
책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다.
쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다.
이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다.
클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만
@ -167,7 +166,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
| CRD | 애그리게이트 API |
| --------------------------- | -------------- |
| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | Go로 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. |
| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. |
| 실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다. | 추가 서비스를 생성하면 실패할 수 있다. |
| CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다. | 업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다. |
| 여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다. | 인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다. |

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

@ -114,6 +114,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
* [Charmed Operator Framework](https://juju.is/)
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를
사용하여 직접 구현하기

2
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -32,7 +32,7 @@ weight: 40
서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
스토리지에 etcd를 사용하여 확장 API 서버와 컨트롤러로 구현된다. 또한 쿠버네티스 1.7 이상에서 제공하는 [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하여 API를 제공한다.
이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
<br>

9
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
View File

@ -81,12 +81,11 @@ deployment.apps/nginx-deployment created
* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
* `spec` - 오브젝트에 대해 어떤 상태를 의도하는지
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, 파드에 대한 `spec` 포맷은
[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, API 내 파드에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 대한 레퍼런스에서,
디플로이먼트에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)에 대한 레퍼런스에서 확인할 수 있다.
해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다.
## {{% heading "whatsnext" %}}

3
content/ko/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -59,6 +59,9 @@ kube-system Active 1d
* `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
* `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
* `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
* `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를
보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.
### 요청에 네임스페이스 설정하기

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

@ -125,7 +125,7 @@ spec:
이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의
레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서
동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는
점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다.
점을 제외하고는 `requiredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingRequiredDuringExecution` 를 제공할 계획이다.
따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이
될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고

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

@ -93,9 +93,9 @@ shape:
``` yaml
resources:
- name: CPU
- name: cpu
weight: 1
- name: Memory
- name: memory
weight: 1
```
@ -105,9 +105,9 @@ resources:
resources:
- name: intel.com/foo
weight: 5
- name: CPU
- name: cpu
weight: 3
- name: Memory
- name: memory
weight: 1
```
@ -124,16 +124,16 @@ resources:
```
intel.com/foo : 2
Memory: 256MB
CPU: 2
memory: 256MB
cpu: 2
```
리소스의 가중치는 다음과 같다.
```
intel.com/foo : 5
Memory: 1
CPU: 3
memory: 1
cpu: 3
```
FunctionShapePoint {{0, 0}, {100, 10}}
@ -143,13 +143,13 @@ FunctionShapePoint {{0, 0}, {100, 10}}
```
Available:
intel.com/foo: 4
Memory: 1 GB
CPU: 8
memory: 1 GB
cpu: 8
Used:
intel.com/foo: 1
Memory: 256MB
CPU: 1
memory: 256MB
cpu: 1
```
노드 점수는 다음과 같다.
@ -162,13 +162,13 @@ intel.com/foo = resourceScoringFunction((2+1),4)
= rawScoringFunction(75)
= 7 # floor(75/10)
Memory = resourceScoringFunction((256+256),1024)
memory = resourceScoringFunction((256+256),1024)
= (100 -((1024-512)*100/1024))
= 50 # requested + used = 50% * available
= rawScoringFunction(50)
= 5 # floor(50/10)
CPU = resourceScoringFunction((2+1),8)
cpu = resourceScoringFunction((2+1),8)
= (100 -((8-3)*100/8))
= 37.5 # requested + used = 37.5% * available
= rawScoringFunction(37.5)
@ -183,12 +183,12 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
```
Available:
intel.com/foo: 8
Memory: 1GB
CPU: 8
memory: 1GB
cpu: 8
Used:
intel.com/foo: 2
Memory: 512MB
CPU: 6
memory: 512MB
cpu: 6
```
노드 점수는 다음과 같다.
@ -207,7 +207,7 @@ Memory = resourceScoringFunction((256+512),1024)
= rawScoringFunction(75)
= 7
CPU = resourceScoringFunction((2+6),8)
cpu = resourceScoringFunction((2+6),8)
= (100 -((8-8)*100/8))
= 100
= rawScoringFunction(100)

2
content/ko/docs/concepts/security/controlling-access.md
View File

@ -139,7 +139,7 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수
- 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
- TLS가 없다.
- 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
- 기본 포트는 8080이다.
- 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈을 **우회한다**.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.

1
content/ko/docs/concepts/security/overview.md
View File

@ -60,6 +60,7 @@ Amazon Web Services | https://aws.amazon.com/security/ |
Google Cloud Platform | https://cloud.google.com/security/ |
IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
{{< /table >}}

2
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다.
[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)이 필요하다.
{{< note >}}
만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서

4
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -217,13 +217,13 @@ DNS 정책은 파드별로 설정할 수 있다.
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
자세한 내용은
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서
확인할 수 있다.
- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서
[관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서
확인할 수 있다.
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.

4
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -164,8 +164,8 @@ Events: <none>
요청은 _p_ 경로에 일치한다.
{{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막
요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와
`/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}}
요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 는
`/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 와는 일치하지 않는다). {{< /note >}}
### 예제

3
content/ko/docs/concepts/services-networking/network-policies.md
View File

@ -154,6 +154,7 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto
의심스러운 경우, `kubectl describe` 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다.
<a name="behavior-of-ipblock-selectors"></a>
__ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
@ -252,7 +253,7 @@ spec:
```
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우,
네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가
네임스페이스 `default` 에 레이블이 `role=db` 인 모든 파드가
TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.

28
content/ko/docs/concepts/services-networking/service.md
View File

@ -183,6 +183,13 @@ subsets:
위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로
라우팅된다. `192.0.2.42:9376` (TCP)
{{< note >}}
쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다.
셀렉터가 없는 서비스에 대해서 `kubectl proxy <service-name>`과 같은 행위는
이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를
프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다.
{{< /note >}}
ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
@ -242,6 +249,24 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
낮거나 0이면 DNS에 부하가 높아 관리하기가
어려워 질 수 있다.
본 페이지의 뒷 부분에서 다양한 kube-proxy 구현의 동작에 대해 읽을 수 있다.
우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이
수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고,
이는 때로는 리부트 전까지 정리되지 않을 수도 있다.
그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹
프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다.
비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이
아니기 때문에 구현된 그대로만 사용할 수 있다.
### 구성
kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어,
운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다.
마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의
@ -428,8 +453,7 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. [도커 링크
호환](https://docs.docker.com/userguide/dockerlinks/) 변수
([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와
호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.

39
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -130,8 +130,10 @@ Events: <none>
`Retain` 반환 정책은 리소스를 수동으로 반환할 수 있게 한다. 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스 된" 것으로 간주된다. 그러나 이전 요청자의 데이터가 여전히 볼륨에 남아 있기 때문에 다른 요청에 대해서는 아직 사용할 수 없다. 관리자는 다음 단계에 따라 볼륨을 수동으로 반환할 수 있다.
1. 퍼시스턴트볼륨을 삭제한다. PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재한다.
1. 관련 스토리지 자산의 데이터를 수동으로 삭제한다.
1. 연결된 스토리지 자산을 수동으로 삭제하거나 동일한 스토리지 자산을 재사용하려는 경우 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다.
2. 관련 스토리지 자산의 데이터를 수동으로 삭제한다.
3. 연결된 스토리지 자산을 수동으로 삭제한다.
동일한 스토리지 자산을 재사용하려는 경우, 동일한 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다.
#### Delete(삭제)
@ -412,11 +414,19 @@ spec:
접근 모드는 다음과 같다.
* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.
`ReadWriteOnce`
: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.
`ReadWriteMany`
: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.
`ReadWriteOncePod`
: 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다.
[퍼시스턴트 볼륨에 대한 단일 파드 접근 모드 소개](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/) 블로그 기사에서 이에 대해 보다 자세한 내용을 다룬다.
CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
@ -509,7 +519,7 @@ PV는 `storageClassName` 속성을
대부분의 볼륨 유형의 경우 이 필드를 설정할 필요가 없다. [AWS EBS](/ko/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) 및 [Azure Disk](/ko/docs/concepts/storage/volumes/#azuredisk) 볼륨 블록 유형에 자동으로 채워진다. [로컬](/ko/docs/concepts/storage/volumes/#local) 볼륨에 대해서는 이를 명시적으로 설정해야 한다.
{{< /note >}}
PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다.
PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. 노드 어피니티를 명기하기 위해서는, PV의 `.spec`에 `nodeAffinity`를 설정한다. [퍼시스턴트볼륨](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) API 레퍼런스에 해당 필드에 대해 보다 자세한 내용이 있다.
### 단계(Phase)
@ -897,16 +907,15 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우
사용자는 PVC가 필요한 구성을 배포할 수 없음).
## {{% heading "whatsnext" %}}
## {{% heading "whatsnext" %}}
* [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기
* [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기
* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기
### 참고
### API 레퍼런스 {#reference}
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
본 페이지에 기술된 API에 대해서 다음을 읽어본다.
* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/)
* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/)

41
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -17,6 +17,8 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="
하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=<time zone>"을 추가해서 타임존을 명기할 수 있으며, 항상 `CRON_TZ`를 설정하는 것을 권장한다.
{{< caution >}}
모든 **크론잡** `일정:` 시간은
{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
@ -53,15 +55,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
### 크론 스케줄 문법
```
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
# ┌────────────────── 타임존 (옵션)
# | ┌───────────── 분 (0 - 59)
# | │ ┌───────────── 시 (0 - 23)
# | │ │ ┌───────────── 일 (1 - 31)
# | │ │ │ ┌───────────── 월 (1 - 12)
# | │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# | │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# | │ │ │ │ │
# | │ │ │ │ │
# CRON_TZ=UTC * * * * *
```
@ -74,9 +77,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
`0 0 13 * 5`
`CRON_TZ=UTC 0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
@ -132,8 +135,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
## {{% heading "whatsnext" %}}
[크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은
크론잡 `schedule` 필드의 포맷을 문서화 한다.
크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
* 크론잡이 의존하고 있는 [파드](/ko/docs/concepts/workloads/pods/)와
[잡](/ko/docs/concepts/workloads/controllers/job/) 두 개념에
대해 배운다.
* 크론잡 `.spec.schedule` 필드의 [형식](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)에
대해서 읽는다.
* 크론잡을 생성하고 다루기 위한 지침 및
크론잡 매니페스트의 예제로
[크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
* `CronJob`은 쿠버네티스 REST API의 일부이다.
{{< api-reference page="workload-resources/cron-job-v1" >}}
오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.

22
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -185,7 +185,7 @@ nodeAffinity:
필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는
다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다.
사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면
사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=orphan` 를 명시하면
파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면,
새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
`updateStrategy` 에 따라 파드를 교체한다.
@ -213,7 +213,7 @@ nodeAffinity:
어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
생성하는 것보다는 데몬 셋을 사용해야 한다.
### 스태틱(static) 파드
### 스태틱(static) 파드 {#static-pods}
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
@ -233,3 +233,21 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다.
* 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
컴포넌트를 기동하는데 유용한
[스태틱 파드](#static-pods)에 대해 배운다.
* 데몬셋을 어떻게 사용하는지 알아본다.
* [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/)
* [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)
(예를 들어, 롤 아웃이 예상대로 동작하지 않은 경우).
* [쿠버네티스가 파드를 노드에 할당하는 방법](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 이해한다.
* 데몬셋으로 구동되곤 하는, [디바이스 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)과
[애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다.
* `DaemonSet`은 쿠버네티스 REST API에서 상위-수준 리소스이다.
데몬셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/daemon-set-v1" >}}
오브젝트 정의를 읽는다.

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

@ -73,10 +73,6 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
`--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다.
기록된 변경사항은 향후 인트로스펙션(introspection)에 유용하다. 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
{{< /note >}}
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
@ -167,13 +163,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
```shell
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
또는 다음의 명령어를 사용한다.
```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
다음과 유사하게 출력된다.
@ -368,7 +364,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
```
이와 유사하게 출력된다.
@ -483,15 +479,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
```
`CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
* 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* `kubectl` 명령어 이용시 `--record` 플래그를 추가해서 리소스 변경을 저장한다.
* 수동으로 리소스 매니페스트 편집.
2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
@ -504,7 +499,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@ -565,7 +560,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@ -1174,3 +1169,14 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은
일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* [디플로이먼트를 사용해서 상태를 유지하지 않는 애플리케이션을 구동한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
* `Deployment`는 쿠버네티스 REST API에서 상위-수준 리소스이다.
디플로이먼트 API를 이해하기 위해서
{{< api-reference page="workload-resources/deployment-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

23
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -25,6 +25,8 @@ weight: 50
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
<!-- body -->
## 예시 잡 실행하기
@ -294,7 +296,7 @@ spec:
`restartPolicy` 는 잡 자체에 적용되는 것이 아니라 파드에 적용된다는 점을 유념한다. 잡의 상태가 `type: Failed` 이 되면, 잡의 자동 재시작은 없다.
즉, `.spec.activeDeadlineSeconds` 와 `.spec.backoffLimit` 로 활성화된 잡의 종료 메커니즘은 영구적인 잡의 실패를 유발하며 이를 해결하기 위해 수동 개입이 필요하다.
## 완료된 잡을 자동으로 정리
## 완료된 잡을 자동으로 정리 {#clean-up-finished-jobs-automatically}
완료된 잡은 일반적으로 시스템에서 더 이상 필요로 하지 않는다. 시스템 내에
이를 유지한다면 API 서버에 부담이 된다.
@ -522,7 +524,7 @@ Events:
실행되기를 원하지만, 잡이 생성한 나머지 파드에는 다른
파드 템플릿을 사용하고 잡으로 하여금 새 이름을 부여하기를 원한다.
그러나 관련된 필드들은 업데이트가 불가능하기 때문에 잡을 업데이트할 수 없다.
따라서 `kubectl delete jobs/old --cascade=false` 를 사용해서
따라서 `kubectl delete jobs/old --cascade=orphan` 명령을 사용해서
잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
@ -638,6 +640,19 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다.
## 크론잡 {#cron-jobs}
## {{% heading "whatsnext" %}}
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
* [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
* 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.
* `Job`은 쿠버네티스 REST API의 일부이다.
잡 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/job-v1" >}}
오브젝트 정의를 읽은다.
* 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다.

13
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -408,3 +408,16 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
* 레플리카셋에 의존해서 동작하는 [디플로이먼트로 스테이트리스 애플리케이션을 실행한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
* `ReplicaSet`는 쿠버네티스 REST API의 상위-수준 리소스이다.
레플리카셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/replica-set-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

11
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -193,7 +193,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적
해당 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 삭제할 수 있다.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
@ -285,6 +285,11 @@ API 오브젝트에 대한 더 자세한 것은
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
## 더 자세한 정보는
## {{% heading "whatsnext" %}}
[스테이트리스 애플리케이션 디플로이먼트 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)를 참고한다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 레플리케이션 컨트롤러를 대신하는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
* `ReplicationController`는 쿠버네티스 REST API의 일부이다.
레플리케이션 컨트롤러 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/replication-controller-v1" >}}
오브젝트 정의를 읽는다.

16
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -297,3 +297,19 @@ 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-replicated-stateful-application/)의 예시를 따른다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 스테이트풀셋을 사용하는 방법을 알아본다.
* [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
* [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다.
* [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
* [스테이트풀셋 확장하기](/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
스테이트풀셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/stateful-set-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

16
content/ko/docs/concepts/workloads/pods/_index.md
View File

@ -258,11 +258,8 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
## 컨테이너에 대한 특권 모드
리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. 파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
{{< note >}}
이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@ -286,6 +283,13 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
{{< note >}}
스태틱 파드의 `스펙(spec)`은 다른 API 오브젝트
(예를 들면, {{< glossary_tooltip text="서비스어카운트" term_id="service-account" >}},
{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}},
{{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다.
{{< /note >}}
## 컨테이너 프로브
_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
@ -305,9 +309,9 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
[파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
{{< api-reference page="workload-resources/pod-v1" >}}
오브젝트 정의는 오브젝트를 상세히 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns/)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.

22
content/ko/docs/concepts/workloads/pods/init-containers.md
View File

@ -32,12 +32,14 @@ weight: 40
그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
타입 오브젝트들의 JSON 배열로서 추가한다.
초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를
통해서 컨테이너 상태 배열로 반환된다
(`.status.containerStatuses` 필드와 유사하게).
[파드 스펙](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 `initContainers` 필드를
`container` 항목(앱 `container` 필드 및 내용과 유사한)들의 배열로서 추가한다.
[컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)에 대한 더 상세한 사항은
API 레퍼런스를 참고한다.
초기화 컨테이너의 상태는 컨테이너
상태의 배열(`.status.containerStatuses` 필드와 유사)로 `.status.initContainerStatuses`
필드에 반환된다.
### 일반적인 컨테이너와의 차이점
@ -278,9 +280,11 @@ myapp-pod 1/1 Running 0 9m
`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
초기화 컨테이너들이 실패를
영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다.
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`를 사용한다.
Active deadline은 초기화 컨테이너를 포함한다.
그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다.

30
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -230,20 +230,9 @@ graph BT
이 상황을 극복하기 위해서는 사용자가 `maxSkew` 의 증가 또는 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 제약 조건 중 하나를 수정할 수 있다.
### 규칙
### 노드 어피니티(Affinity) 및 노드 셀렉터(Selector)와의 상호 작용
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
- 만약 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity` 가 정의되어 있으면, 일치하지 않는 노드는 무시하게 된다.
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
@ -283,6 +272,21 @@ graph BT
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다.
### 기타 눈에 띄는 의미(semantics)
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
### 클러스터 수준의 기본 제약 조건
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본

60
content/ko/docs/contribute/new-content/_index.md
View File

@ -1,4 +1,64 @@
---
title: 새로운 콘텐츠 기여하기
content_type: concept
main_menu: true
weight: 20
---
<!-- overview -->
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
<!-- body -->
## 기여에 대한 기본 사항
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각
언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에
의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어,
한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
## 시작하기 전에 {#before-you-begin}
### CNCF CLA 서명 {#sign-the-cla}
모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
### 사용할 Git 브랜치를 선택한다
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
시나리오 | 브랜치
:---------|:------------
현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main`
기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
{{< note >}}
풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
제출자(제출자인 여러분만)가 이를 변경할 수 있다.
{{< /note >}}
### PR 당 언어
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
## 기여자를 위한 도구들
`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.

65
content/ko/docs/contribute/new-content/overview.md
View File

@ -1,65 +0,0 @@
---
title: 새로운 콘텐츠 기여하기에 대한 개요
linktitle: 개요
content_type: concept
main_menu: true
weight: 5
---
<!-- overview -->
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
<!-- body -->
## 기여하기에 대한 기본
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각
언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에
의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어,
한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
## 시작하기 전에 {#before-you-begin}
### CNCF CLA 서명 {#sign-the-cla}
모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
### 사용할 Git 브랜치를 선택한다
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
시나리오 | 브랜치
:---------|:------------
현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main`
기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
{{< note >}}
풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
제출자(제출자인 여러분만)가 이를 변경할 수 있다.
{{< /note >}}
### PR 당 언어
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
## 기여자를 위한 도구들
`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다.

6
content/ko/docs/home/_index.md
View File

@ -1,4 +1,6 @@
---
title: 쿠버네티스 문서
noedit: true
cid: docsHome
@ -20,9 +22,9 @@ overview: >
쿠버네티스는 배포, 스케일링, 그리고 컨테이너화된 애플리케이션의 관리를 자동화 해주는 오픈 소스 컨테이너 오케스트레이션 엔진이다. 본 오픈 소스 프로젝트는 Cloud Native Computing Foundation(<a href="https://www.cncf.io/about">CNCF</a>)가 주관한다.
cards:
- name: concepts
title: "기초 이해하기"
title: "쿠버네티스 이해하기"
description: "쿠버네티스와 쿠버네티스의 기본 개념을 배운다."
button: "개념 배우기"
button: "개념 살펴보기"
button_path: "/ko/docs/concepts"
- name: tutorials
title: "쿠버네티스 사용해보기"

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

@ -64,6 +64,8 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
* [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
* 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
[포트와 프로토콜](/docs/reference/ports-and-protocols/) 리스트
## API 설정
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는

38
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -1,4 +1,9 @@
---
title: 인가 개요
content_type: concept
weight: 60
@ -187,22 +192,33 @@ status:
하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
## 파드 생성을 통한 권한 확대
## 워크로드 생성 및 수정을 통한 권한 확대 {#privilege-escalation-via-pod-creation}
네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.
{{< caution >}}
시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
이는 인가 모드에 관계없이 적용된다.
시스템 관리자는 파드 생성/수정에 대한 접근 권한을 부여할 때 주의한다.
[권한 확대 경로](#escalation-paths)에서 접근 권한이 잘못 사용되었을 때의 상세사항을 확인할 수 있다.
{{< /caution >}}
### 권한 확대 경로 {#escalation-paths}
- 네임스페이스 내의 임의의 시크릿을 마운트
- 다른 워크로드를 위한 시크릿으로의 접근에 사용될 수 있음
- 더 권한이 많은 서비스 어카운트의 서비스 어카운트 토큰 획득에 사용될 수 있음
- 네임스페이스 내의 임의의 서비스 어카운트를 사용
- 다른 워크로드인것처럼 사칭하여 쿠버네티스 API 액션을 수행할 수 있음
- 서비스 어카운트가 갖고 있는 '권한이 필요한 액션'을 수행할 수 있음
- 네임스페이스 내의 다른 워크로드를 위한 컨피그맵을 마운트
- 다른 워크로드를 위한 정보(예: DB 호스트 이름) 획득에 사용될 수 있음
- 네임스페이스 내의 다른 워크로드를 위한 볼륨을 마운트
- 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음
{{< caution >}}
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다.
{{< /caution >}}
## {{% heading "whatsnext" %}}

2
content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
View File

@ -67,7 +67,7 @@ weight: 50
defaultMode: 420 # 0644
sources:
- serviceAccountToken:
expirationSeconds: 3600
expirationSeconds: 3607
path: token
- configMap:
items:

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

@ -165,8 +165,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | |
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
| `ProcMountType` | `false` | 알파 | 1.12 | |
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
| `QOSReserved` | `false` | 알파 | 1.11 | |
| `ReadWriteOncePod` | `false` | 알파 | 1.22 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
@ -789,10 +789,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
잡 컨트롤러는 완료된 파드를 추적하기 위해
완료된 파드의 잡 상태 필드를 사용한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
@ -800,10 +796,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
비동기 조정을 허용한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아있는 파드에
의존하지 않고 잡 완료를 추적할 수 있다.
파드 finalizers는 잡 상태 필드와
아직 구성되지 않은 파드를 추적할 수 있다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
잡 컨트롤러는 완료된 파드를 추적하기 위해
완료된 파드의 잡 상태 필드를 사용한다.
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
kubelet 구성을 로드할 수 있다.
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
@ -1012,18 +1008,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다.
- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
확장성과 성능을 향상시킨다.
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
- `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다.
- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
[RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
참고한다.
- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
확장성과 성능을 향상시킨다.
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
- `WindowsHostProcessContainers`: 윈도우 노드에서 `HostProcess`
컨테이너 지원을 활성화한다.
## {{% heading "whatsnext" %}}

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

File diff suppressed because one or more lines are too long

23
content/ko/docs/reference/glossary/sysctl.md Normal file
View File

@ -0,0 +1,23 @@
---
title: sysctl
id: sysctl
date: 2019-02-12
full_link: /docs/tasks/administer-cluster/sysctl-cluster/
short_description: >
유닉스 커널 파라미터를 가져오거나 설정하는 데 사용하는 인터페이스
aka:
tags:
- tool
---
`sysctl`은 동작 중인 유닉스 커널의 속성을 읽거나 수정하는 데 사용하는
(준)표준 인터페이스이다.
<!--more-->
유닉스 계열 시스템에서 `sysctl`은 관리자가 이러한 설정을 확인하고 수정하는데 사용하는 도구의
이름이기도 하고, 해당 도구가 사용하는 시스템 콜이기도
하다.
{{< glossary_tooltip text="컨테이너" term_id="container" >}} 런타임과
네트워크 플러그인은 특정 방식으로 설정된 `sysctl` 값에 의존성이 있을 수 있다.

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

@ -1,5 +1,11 @@
---
title: 쿠버네티스 보안과 공개 정보
aliases: [/security/]
content_type: concept
weight: 20
---
@ -11,17 +17,19 @@ weight: 20
<!-- body -->
## 보안 공지
보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입하세요.
보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입한다.
[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다.
[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드도 구독할 수 있다.
## 취약점 보고
우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다.
보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes)에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다. 또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes)에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다.
[제품 보안 위원회 구성원](https://git.k8s.io/security/README.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.
또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
[보안 대응 위원회(Security Response Committee) 구성원](https://git.k8s.io/security/README.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.
### 언제 취약점을 보고해야 하는가?
@ -39,13 +47,13 @@ weight: 20
## 보안 취약점 대응
각 보고서는 제품 보안 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 [보안 릴리스 프로세스](https://git.k8s.io/security/security-release-process.md#disclosures)가 시작된다.
각 보고서는 보안 대응 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 [보안 릴리스 프로세스](https://git.k8s.io/security/security-release-process.md#disclosures)가 시작된다.
제품 보안 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다.
보안 대응 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다.
보안 문제가 심사에서 확인된 수정, 릴리스 계획으로 이동함에 따라 리포터를 계속 업데이트할 것이다.
## 공개 시기
공개 날짜는 쿠버네티스 제품 보안 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지입니다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 제품 보안 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다.
공개 날짜는 쿠버네티스 보안 대응 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 보안 대응 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다.

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

@ -1,4 +1,6 @@
---
title: kubectl 개요
content_type: concept
weight: 20
@ -69,6 +71,32 @@ kubectl [command] [TYPE] [NAME] [flags]
도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
## 클러스터 내 인증과 네임스페이스 오버라이드
기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
**`POD_NAMESPACE` 환경 변수**
`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
**kubectl이 서비스어카운트 토큰을 관리하는 방법**
만약
* 쿠버네티스 서비스 어카운트 토큰 파일이
`/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
* kubectl 명령에 네임스페이스를 명시하지 않으면
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
이는 클러스터 외부에서 실행되었을 때와는 다른데,
kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우
kubectl은 `default` 네임스페이스에 대해 동작한다.
## 명령어
다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.

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

@ -131,14 +131,12 @@ profiles:
필터링한다.
익스텐션 포인트: `filter`.
- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지
확인한다. 점수는 `LeastAllocated`(기본값), `MostAllocated`, `RequestedToCapacityRatio` 등 3가지 전략 중 하나를 사용할 수 있다.
확인한다. 점수는 `LeastAllocated`(기본값), `MostAllocated`, `RequestedToCapacityRatio` 등
3가지 전략 중 하나를 사용할 수 있다.
익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을
얻을 수 있는 노드를 선호한다.
익스텐션 포인트: `score`.
- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를
선호한다.
익스텐션 포인트: `Score`.
- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
또는 바인딩할 수 있는지 확인한다.
익스텐션 포인트: `preFilter`, `filter`, `reserve`, `preBind`, `score`.
@ -263,3 +261,4 @@ profiles:
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기

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

@ -8,7 +8,7 @@ card:
weight: 40
---
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다.
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터 생성을 위한 "빠른 경로"의 모범 사례로 `kubeadm init` 및 `kubeadm join` 을 제공하도록 만들어진 도구이다.
kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다.

8
content/ko/docs/reference/tools/_index.md
View File

@ -8,7 +8,7 @@ no_list: true
---
<!-- overview -->
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이 되는 몇 가지 도구를 포함한다.
<!-- body -->
@ -24,10 +24,14 @@ no_list: true
클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.
## Helm
{{% thirdparty-content single="true" %}}
[Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다.
이 패키지는 _Helm charts_ 라고 알려져 있다.
Helm은 미리 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 제 3자가
관리하는 도구로, 쿠버네티스 차트(charts)라고도 알려져 있다.
Helm의 용도
* 쿠버네티스 차트로 배포된 인기있는 소프트웨어를 검색하고 사용
@ -38,7 +42,7 @@ Helm의 용도
## Kompose
[`Kompose`](https://github.com/kubernetes/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다.
[`Kompose`](https://github.com/kubernetes/kompose)는 도커 컴포즈(Compose) 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다.
Kompose의 용도

2
content/ko/docs/reference/using-api/health-checks.md
View File

@ -16,7 +16,7 @@ weight: 50
`healthz` 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 `livez` 와 `readyz` 엔드포인트를 사용해야 한다.
`livez` 엔드포인트는 `--livez-grace-period` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 시작 대기 시간을 지정할 수 있다.
`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
API 서버의 `health`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
API 서버의 `healthz`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.

60
content/ko/docs/setup/best-practices/certificates.md
View File

@ -36,11 +36,13 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
## 인증서를 저장하는 위치
만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernetes/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다.
만약 쿠버네티스를 kubeadm으로 설치했다면, 대부분의 인증서는 `/etc/kubernetes/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이나, kubeadm이 `/etc/kubernetes`에 저장하는 사용자 어카운트 인증서는 예외이다.
## 인증서 수동 설정
필요한 인증서를 kubeadm으로 생성하기 싫다면 다음 방법 중 하나로 생성할 수 있다.
필요한 인증서를 kubeadm으로 생성하기 싫다면, 단일 루트 CA를 이용하거나 모든 인증서를 제공하여 생성할 수 있다. 소유한 인증기관을 이용해서 생성하는 방법에 대해서는 [인증서](/ko/docs/tasks/administer-cluster/certificates/)를 살펴본다.
인증서를 관리하는 방법에 대해서는 [kubeadm을 사용한 인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)를 살펴본다.
### 단일 루트 CA
@ -55,7 +57,16 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 위해서 |
위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 `sa.key` 와 `sa.pub` 을 얻는 것이 필요하다.
다음은 이전 표에 나온 CA 키와 인증서 파일을 보여준다.
```
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key
```
### 모든 인증서
이런 개인키를 API 서버에 복사하기 원치 않는다면, 모든 인증서를 스스로 생성할 수 있다.
@ -72,7 +83,8 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/ko/docs/reference/setup-tools/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/ko/docs/reference/setup-tools/kubeadm/)이 사용하는
로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.
@ -95,9 +107,10 @@ kubeadm 사용자만 해당:
{{< /note >}}
### 인증서 파일 경로
### 인증서 파일 경로 {#certificate-paths}
인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/ko/docs/reference/setup-tools/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정해야 한다.
인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/ko/docs/reference/setup-tools/kubeadm/)에서 사용되는 것처럼).
경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정해야 한다.
| 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@ -123,6 +136,32 @@ kubeadm 사용자만 해당:
| sa.key | | kube-controller-manager | --service-account-private-key-file |
| | sa.pub | kube-apiserver | --service-account-key-file |
다음은 키와 인증서를 모두 생성할 때에 제공해야 하는 [이전 표에 있는](#certificate-paths) 파일의 경로를 보여준다.
```
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
```
## 각 사용자 계정을 위한 인증서 설정하기
반드시 이런 관리자 계정과 서비스 계정을 설정해야 한다.
@ -142,7 +181,7 @@ kubeadm 사용자만 해당:
1. 각 환경 설정에 대해 다음과 같이 `kubectl`를 실행한다.
```shell
```
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
@ -157,3 +196,12 @@ KUBECONFIG=<filename> kubectl config use-context default-system
| kubelet.conf | kubelet | 클러스터 각 노드를 위해 필요하다. |
| controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야 한다. |
| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야 한다. |
다음의 파일은 이전 표에 나열된 파일의 전체 경로를 보여준다.
```
/etc/kubernetes/admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf
```

3
content/ko/docs/setup/learning-environment/_index.md
View File

@ -11,7 +11,7 @@ weight: 20
{{/* If you're localizing this page, you only need to copy the front matter */}}
{{/* and add a redirect into "/static/_redirects", for YOUR localization. */}}
-->
<!--
## kind
[`kind`](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
@ -31,3 +31,4 @@ kind를 시작하고 실행하기 위해 해야 할 일이 나와 있다.
툴을 설치하고 싶으면
[시작하기!](https://minikube.sigs.k8s.io/docs/start/) 공식 가이드를
참조하기 바란다.
-->

6
content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
View File

@ -9,12 +9,12 @@ weight: 40
<!-- overview -->
이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에
대해서는 `ClusterConfiguration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
대해서는 `Cluster Configuration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
kube-proxy의 경우, `KubeletConfiguration`과 `KubeProxyConfiguration`을 각각 사용할 수 있다.
이 모든 옵션이 kubeadm 구성 API를 통해 가용하다.
구성의 각 필드 상세 사항은
[API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 찾아볼 수 있다.
[API 참조 페이지](/docs/reference/config-api/kubeadm-config.v1beta3/)에서 찾아볼 수 있다.
{{< note >}}
kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다.
@ -202,7 +202,7 @@ kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을
kube-proxy를 사용자 정의하려면, `KubeProxyConfiguration`을 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration`
다음에 두고 `kubeadm init`에 전달하면 된다.
자세한 사항은 [API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 살펴볼 수 있다.
자세한 사항은 [API 참조 페이지](/docs/reference/config-api/kubeadm-config.v1beta3/)에서 살펴볼 수 있다.
{{< note >}}
kubeadm은 kube-proxy를 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로 배포한다. 이것은

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

@ -10,7 +10,8 @@ card:
<!-- overview -->
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">이 페이지에서는 `kubeadm` 툴박스를 설치하는 방법을 보여준다.
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px"></img>
이 페이지에서는 `kubeadm` 툴박스 설치 방법을 보여준다.
이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다.
@ -31,6 +32,7 @@ card:
<!-- steps -->
## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address}
* 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
* product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다.
@ -65,31 +67,9 @@ sudo sysctl --system
자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
## 필수 포트 확인 {#check-required-ports}
### 컨트롤 플레인 노드
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|----------|-----------|------------|-------------------------|---------------------------|
| TCP | 인바운드 | 6443\* | 쿠버네티스 API 서버 | 모두 |
| TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd |
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
| TCP | 인바운드 | 10251 | kube-scheduler | 자체 |
| TCP | 인바운드 | 10252 | kube-controller-manager | 자체 |
### 워커 노드
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 |
|----------|-----------|-------------|-----------------------|-------------------------|
| TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 |
| TCP | 인바운드 | 30000-32767 | NodePort 서비스† | 모두 |
† [NodePort 서비스](/ko/docs/concepts/services-networking/service/)의 기본 포트 범위.
*로 표시된 모든 포트 번호는 재정의할 수 있으므로, 사용자 지정 포트도
열려 있는지 확인해야 한다.
etcd 포트가 컨트롤 플레인 노드에 포함되어 있지만, 외부 또는 사용자 지정 포트에서
자체 etcd 클러스터를 호스팅할 수도 있다.
[필수 포트들](/docs/reference/ports-and-protocols/)은
쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
한다.
사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한

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

@ -1,16 +1,24 @@
---
title: 쿠버네티스의 윈도우 지원 소개
title: 쿠버네티스에서 윈도우 컨테이너
content_type: concept
weight: 65
---
<!-- overview -->
{{< note >}}
본 문서의 영어 원문([Windows containers in Kubernetes](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/))은 변경되었습니다.
최신 내용은 원문을 통해 확인하시기 바랍니다.
본 문서에 대한 갱신은 기여를 통해 진행되며, 갱신이 완료되면 해당 알림은 제거됩니다.
{{< /note >}}
윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및
애플리케이션의 상당 부분을 구성한다.
[윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을

319
content/ko/docs/tasks/access-application-cluster/ingress-minikube.md Normal file
View File

@ -0,0 +1,319 @@
---
title: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기
content_type: task
weight: 100
---
<!-- overview -->
[인그레스](/ko/docs/concepts/services-networking/ingress/)는 클러스터의 서비스에 대한 외부 액세스를 허용하는 규칙을 정의하는
API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)는 인그레스에 설정된 규칙을 이행한다.
이 페이지에서는 HTTP URI에 따라 요청을 Service web 또는 web2로 라우팅하는 간단한 인그레스를 설정하는 방법을 보여준다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## Minikube 클러스터 생성하기
1. **터미널 실행**을 클릭한다.
{{< kat-button >}}
1. (선택 사항) Minikube를 로컬로 설치한 경우 다음 명령을 실행한다.
```shell
minikube start
```
## 인그레스 컨트롤러 활성화
1. NGINX 인그레스 컨트롤러를 활성화하기 위해 다음 명령을 실행한다.
```shell
minikube addons enable ingress
```
1. NGINX 인그레스 컨트롤러가 실행 중인지 확인한다.
{{< tabs name="tab_with_md" >}}
{{% tab name="minikube v1.19 or later" %}}
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
Output:
```
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
```
{{% /tab %}}
{{% tab name="minikube v1.18.1 or earlier" %}}
```shell
kubectl get pods -n kube-system
```
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
Output:
```
NAME READY STATUS RESTARTS AGE
default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m
kube-addon-manager-minikube 1/1 Running 0 3m
kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m
kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
storage-provisioner 1/1 Running 0 2m
```
{{% /tab %}}
{{< /tabs >}}
```shell
kubectl get pods -n ingress-nginx
```
{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
Output:
```shell
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s
ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s
ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s
```
## hello, world 앱 배포하기
1. 다음 명령을 사용하여 디플로이먼트(Deployment)를 생성한다.
```shell
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
```
Output:
```shell
deployment.apps/web created
```
1. 디플로이먼트를 노출시킨다.
```shell
kubectl expose deployment web --type=NodePort --port=8080
```
Output:
```shell
service/web exposed
```
1. 서비스(Service)가 생성되고 노드 포트에서 사용할 수 있는지 확인한다.
```shell
kubectl get service web
```
Output:
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web NodePort 10.104.133.249 <none> 8080:31637/TCP 12m
```
1. 노드포트(NodePort)를 통해 서비스에 접속한다.
```shell
minikube service web --url
```
Output:
```shell
http://172.17.0.15:31637
```
{{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}}
Output:
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는
인그레스 리소스를 사용하여 앱에 액세스할 수 있다.
## 인그레스 리소스 생성하기
다음 파일은 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스 리소스다.
1. 다음 파일을 통해 `example-ingress.yaml`을 만든다.
{{< codenew file="service/networking/example-ingress.yaml" >}}
1. 다음 명령어를 실행하여 인그레스 리소스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
```
Output:
```shell
ingress.networking.k8s.io/example-ingress created
```
1. IP 주소가 설정되었는지 확인한다.
```shell
kubectl get ingress
```
{{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}}
```shell
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress <none> hello-world.info 172.17.0.15 80 38s
```
1. `/etc/hosts` 파일의 맨 아래에 다음 행을 추가한다.
{{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}}
```
172.17.0.15 hello-world.info
```
이것은 hello-world.info에서 Minikube로 요청을 보낸다.
1. 인그레스 컨트롤러가 트래픽을 전달하는지 확인한다.
```shell
curl hello-world.info
```
Output:
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
{{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info에 접속할 수 있다.{{< /note >}}
## 두 번째 디플로이먼트 생성하기
1. 다음 명령을 사용하여 v2 디플로이먼트를 생성한다.
```shell
kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
```
Output:
```shell
deployment.apps/web2 created
```
1. 디플로이먼트를 노출시킨다.
```shell
kubectl expose deployment web2 --port=8080 --type=NodePort
```
Output:
```shell
service/web2 exposed
```
## 인그레스 수정하기
1. 기존 `example-ingress.yaml`을 편집하여 다음 줄을 추가한다.
```yaml
- path: /v2
pathType: Prefix
backend:
service:
name: web2
port:
number: 8080
```
1. 변경 사항을 적용한다.
```shell
kubectl apply -f example-ingress.yaml
```
Output:
```shell
ingress.networking/example-ingress configured
```
## 인그레스 테스트하기
1. Hello World 앱의 첫 번째 버전에 액세스한다.
```shell
curl hello-world.info
```
Output:
```shell
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
```
1. Hello World 앱의 두 번째 버전에 액세스한다.
```shell
curl hello-world.info/v2
```
Output:
```shell
Hello, world!
Version: 2.0.0
Hostname: web2-75cd47646f-t8cjk
```
{{< note >}}Minikube를 로컬에서 실행하는 경우 브라우저에서 hello-world.info 및 hello-world.info/v2에 접속할 수 있다.{{< /note >}}
## {{% heading "whatsnext" %}}
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 더 보기.
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 더 보기.
* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 보기.

44
content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
View File

@ -2,8 +2,9 @@
title: 웹 UI (대시보드)
title: 쿠버네티스 대시보드를 배포하고 접속하기
description: >-
웹 UI(쿠버네티스 대시보드)를 배포하고 접속한다.
content_type: concept
weight: 10
card:
@ -31,36 +32,39 @@ card:
## 대시보드 UI 배포
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다.
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
```
## 대시보드 UI 접근
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
현재, 대시보드는 Bearer 토큰으로 로그인하는 방법을 제공한다.
본 시연을 위한 토큰을 생성하기 위해서는,
[샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
{{< warning >}}
시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
시연 중 생성한 샘플의 사용자에게는 관리자(admin) 권한이 부여되며, 이는 교육 목적으로만 사용한다.
{{< /warning >}}
### 커맨드 라인 프록시
kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드를 사용할 수 있다.
`kubectl` 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드로의
접속을 활성화할 수 있다.
```
kubectl proxy
```
kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
kubectl은 [http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/)를 통해 대시보드에 접속할 수 있게 해줄 것이다.
UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
UI는 _오직_ 커맨드가 실행된 머신에서만 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
{{< note >}}
Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다.
Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
또는 X.509 인증서를 **지원하지 않는다**.
{{< /note >}}
## 웰컴 뷰
@ -75,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
## 컨테이너화 된 애플리케이션 배포
대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다.
애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드할 수 있다.
애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML 또는 JSON _매니페스트(manifest)_ 파일을 업로드할 수 있다.
시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
@ -186,13 +190,14 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
### YAML 또는 JSON 파일 업로드
쿠버네티스는 선언적인 설정을 제공한다.
이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를
이용하여 YAML 또는 JSON 설정 파일에 저장한다.
이 방식에서는 모든 설정이 매니페스트(YAML 또는 JSON 설정 파일)에 저장된다.
매니페스트는 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를
사용한다.
배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신,
애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
배포 마법사를 통해 애플리케이션 세부 사항들을 지정하는 대신, 애플리케이션을 하나 이상의 매니페스트로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
## 대시보드 사용
다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
### 탐색
@ -201,9 +206,10 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데,
이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
대시보드는 몇 가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
#### 어드민 개요
클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다.
노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다.
세부사항은 각 노드들에 대한 사용량, 사양, 상태,
@ -212,7 +218,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
#### 워크로드
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고
애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고
각각의 워크로드 종류는 따로 보여진다.
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
워크로드에 대한 실용적인 정보를 요약한다.
@ -230,9 +236,9 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
#### 스토리지
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트볼륨클레임 리소스들을 보여준다.
#### 컨피그 맵과 시크릿
#### 컨피그맵과 시크릿 {#config-maps-and-secrets}
클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다.
컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.

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

@ -146,11 +146,10 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이
필요할 수 있다.
일부 클러스터에서, API 서버는 인증이 필요하지 않다.
로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
없다. [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은
클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
고 가용성 지원과 충돌할 수 있다.
일부 클러스터에서, API 서버는 인증이 필요하지 않다. 로컬 호스트에서 제공되거나,
방화벽으로 보호될 수 있다. 이에 대한 표준은 없다.
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 클러스터
관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 고 가용성 지원과 충돌할 수 있다.
### API에 프로그래밍 방식으로 접근

3
content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
View File

@ -1,4 +1,7 @@
---
title: DNS 서비스 사용자 정의하기
content_type: task
min-kubernetes-server-version: v1.12

10
content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md
View File

@ -133,10 +133,18 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있
## 구현 지침
![ha-master-gce](/images/docs/ha-master-gce.png)
![ha-control-plane](/docs/images/ha-control-plane.svg)
### 개요
위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다.
- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다.
- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다.
- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다.
추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다.
각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다.
* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.

81
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -9,17 +9,17 @@ weight: 20
<!-- overview -->
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로,
{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
{{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로,
{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
마이너 버전을 건너뛴다.
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
이 페이지 대신 다음의 페이지들을 참고한다.
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
추상적인 업그레이드 작업 절차는 다음과 같다.
@ -45,19 +45,19 @@ weight: 20
## 업그레이드할 버전 결정
OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다.
OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리스 버전({{< skew currentVersion >}})을 찾는다.
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
apt update
apt-cache madison kubeadm
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
# {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
# {{< skew currentVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
# {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
# {{< skew currentVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{< /tabs >}}
@ -74,20 +74,21 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
# {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<br />
- 다운로드하려는 버전이 잘 받아졌는지 확인한다.
@ -120,13 +121,13 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
```shell
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
```
명령이 완료되면 다음을 확인해야 한다.
```
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
@ -169,25 +170,22 @@ sudo kubeadm upgrade apply
- 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
{{< tabs name="k8s_install_kubelet" >}}
{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
<pre>>
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# replace x in {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
</pre>
{{< /tab >}}
{{< tab name="CentOS, RHEL 또는 Fedora" >}}
<pre>
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
</pre>
{{< /tab >}}
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<br />
- kubelet을 다시 시작한다.
@ -216,18 +214,18 @@ sudo systemctl restart kubelet
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
# {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@ -254,20 +252,21 @@ sudo systemctl restart kubelet
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
# {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
<br />
- kubelet을 다시 시작한다.

213
content/ko/docs/tasks/administer-cluster/sysctl-cluster.md Normal file
View File

@ -0,0 +1,213 @@
---
title: 쿠버네티스 클러스터에서 sysctl 사용하기
content_type: task
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여
커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
일부 단계에서는 실행 중인 클러스터의 kubelet에서
커맨드 라인 옵션을 재구성할 필요가 있다.
<!-- steps -->
## 모든 sysctl 파라미터 나열
리눅스에서 sysctl 인터페이스는 관리자들이 런타임에 커널 파라미터를 수정할 수 있도록
허용한다. 파라미터는 `/proc/sys` 가상 파일 시스템을 통해 이용할 수 있다. 파라미터는
다음과 같은 다양한 서브 시스템을 포함한다.
- 커널 (공통 접두사: `kernel.`)
- 네트워크 (공통 접두사: `net.`)
- 가상 메모리 (공통 접두사: `vm.`)
- MDADM (공통 접두사: `dev.`)
- 더 많은 서브 시스템은 [커널 문서](https://www.kernel.org/doc/Documentation/sysctl/README)에 설명되어 있다.
모든 파라미터 리스트를 가져오려면 다음 명령을 실행한다.
```shell
sudo sysctl -a
```
## unsafe sysctl 활성화하기
sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl은
적절한 네임스페이스 뿐만 아니라 동일한 노드의 파드 사이에 _고립_ 되어야 한다. 즉, 하나의
파드에 _safe_ sysctl을 설정한다는 것은 다음을 의미한다.
- 노드의 다른 파드에 영향을 미치지 않아야 한다
- 노드의 상태를 손상시키지 않아야 한다
- CPU 또는 메모리 리소스가 파드의 리소스 제한에 벗어나는 것을
허용하지 않아야 한다
아직까지 대부분 _네임스페이스된_ sysctl은 _safe_ sysctl로 고려되지 않았다.
>>> 다음 sysctl은 _safe_ 명령을 지원한다.
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`,
- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후).
{{< note >}}
`net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다.
{{< /note >}}
kubelet이 더 고립된 방법을 지원하면 추후 쿠버네티스 버전에서
확장될 것이다.
모든 _safe_ sysctl은 기본적으로 활성화된다.
모든 _unsafe_ sysctl은 기본적으로 비활성화되고, 노드별 기본 클러스터 관리자에
의해 수동으로 메뉴얼로 허용되어야 한다.
unsafe sysctl이 비활성화된 파드는 스케줄링되지만, 시작에 실패한다.
위의 경고를 염두에 두고 클러스터 관리자는
고성능 또는 실시간 애플리케이션 조정과 같은
매우 특수한 상황에 대해 특정 _unsafe_ sysctl을 허용할 수 있다. _unsafe_ sysctl은
kubelet 플래그를 사용하여 노드별로 활성화된다. 예를 들면, 다음과 같다.
```shell
kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
```
{{< glossary_tooltip term_id="minikube" >}}의 경우, `extra-config` 플래그를 통해 이 작업을 수행할 수 있다.
```shell
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
```
_네임스페이스_ sysctl만 이 방법을 사용할 수 있다.
## 파드에 대한 sysctl 설정
수많은 sysctl은 최근 리눅스 커널에서 _네임스페이스_ 되어 있다. 이는 노드의 각 파드에
대해 개별적으로 설정할 수 있다는 것이다. 쿠버네티스의 파드 securityContext를 통해
네임스페이스 sysctl만 구성할 수 있다.
다음 sysctls는 네임스페이스로 알려져 있다.
이 목록은 이후 버전의 Linux 커널에서 변경될 수 있다.
- `kernel.shm*`,
- `kernel.msg*`,
- `kernel.sem`,
- `fs.mqueue.*`,
- `net.*` 아래의 파라미터는 컨테이너 네트워킹 네임스페이스에서 설정할 수 있다.
그러나 예외가 존재한다. (예, `net.netfilter.nf_conntrack_max`와 `net.netfilter.nf_conntrack_expect_max`는
컨테이너 네트워킹 네임스페이스에서 설정되지만,
네임스페이스가 없다.)
네임스페이스가 없는 sysctl은 _node-level_ sysctl이라고 부른다.
이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나
특권있는 컨테이너의 데몬셋을 사용하여야 한다.
네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다.
이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인
`net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다.
{{< warning >}}
파라미터의 영향을 파악한 후에만 운영체제가
불안정해지지 않도록 sysctl 파라미터를 수정한다.
{{< /warning >}}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
- name: kernel.msgmax
value: "65536"
...
```
<!-- discussion -->
{{< warning >}}
_unsafe_의 특성으로 인해 _unsafe_sysctl는 위험 부담이 있으며
컨테이너의 잘못된 동작, 리소스 부족 혹은 노드 완전 파손과 같은
심각한 문제를 초래할 수 있다.
{{< /warning >}}
특별한 sysctl 설정이 있는 노드를 클러스터 내에서 _tainted_로 간주하고
sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다.
이를 구현하려면 쿠버네티스 [_테인트(taint)와 톨러레이션(toleration)_ 기능](/docs/reference/generated/kubectl/kubectl-commands/#taint) 을
사용하는 것이 좋다.
두 _unsafe_ sysctl을 명시적으로 활성화하지 않은 노드에서 _unsafe_ sysctl을 사용하는
파드가 시작되지 않는다. _node-level_ sysctl과 마찬가지로
[_테인트와 톨러레이션_ 특징](/docs/reference/generated/kubectl/kubectl-commands/#taint) 또는
[노드 테인트](/docs/concepts/scheduling-eviction/taint-and-toleration/)를
사용하여 해당 파드를 오른쪽 노드에
스케줄하는 것을 추천한다.
## 파드시큐리티폴리시(PodSecurityPolicy)
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
또한 파드시큐리티폴리시의 `forbiddenSysctls` 및/또는 `allowedUnsafeSysctls` 필드에
sysctl 또는 sysctl 패턴 목록을 지정하여 파드에서 설정할
수 있는 sysctl를 제어할 수 있다. sysctl 패턴은 `kernel.*`과 같은 `*`
문자로 끝난다. `*` 문자 자체는
모든 sysctl와 일치한다.
기본적으로 모든 safe sysctl은 허용된다.
`forbiddenSysctls`와 `allowedUnsafeSysctls`는 모두 단순한 sysctl 이름 또는
sysctl 패턴 목록이다(`*`로 끝남). `*` 문자는 모든 sysctl과 일치한다.
`forbiddenSysctls` 필드에는 특정 sysctl이 제외된다.
목록에서 safe sysctl과 unsafe sysctl의 조합을 금지할 수 있다.
sysctl 설정을 금지하기 위해서는 `*`를 사용한다.
`allowedUnsafeSysctls` 필드에 unsafe sysctl을 지정하고 `forbiddenSysctls` 필드가
존재하지 않는 경우, 파드시큐리티폴리시를 사용하여
sysctl을 파드에서 사용할 수 있다.
파드시큐리티폴리시의 모든 unsafe sysctl을 설정하려면 `*`를 사용한다.
이 두 필드를 겹치도록 구성하지 않는다.
이는 지정된 sysctl이 허용 및 금지됨을 의미한다.
{{< warning >}}
파드시큐리티폴리시의 'allowedUnsafeSysctls' 필드를 통해 unsafe sysctl을
허용하는 경우, 해당 노드에서 sysctl이
'--allowed-unsafe-sysctls' kubelet 플래그를 통해 허용되지 않으면,
sysctl을 사용하는 모든 파드가 시작에 실패한다.
{{< /warning >}}
이 예에서는 `kernel.msg` 접두사가 붙은 unsafe sysctl을 설정할 수 있으며,
`kernel.shm_rmid_forced` sysctl의 설정을 허용하지 않는다.
```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
spec:
allowedUnsafeSysctls:
- kernel.msg*
forbiddenSysctls:
- kernel.shm_rmid_forced
...
```

310
content/ko/docs/tasks/configure-pod-container/configure-gmsa.md Normal file
View File

@ -0,0 +1,310 @@
---
title: 윈도우 파드와 컨테이너용 GMSA 구성
content_type: task
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
이 페이지는 윈도우 노드에서 실행되는 파드와 컨테이너용으로 [그룹 관리 서비스 어카운트(Group Managed Service Accounts,](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) GMSA)를 구성하는 방법을 소개한다. 그룹 관리 서비스 어카운트는 자동 암호 관리, 단순화된 서비스 사용자 이름(service principal name, SPN) 관리, 여러 서버에 걸쳐 다른 관리자에게 관리를 위임하는 기능을 제공하는 특정한 유형의 액티브 디렉터리(Active Directory) 계정이다.
쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다. v1.16부터 도커 런타임은 윈도우 워크로드용 GMSA를 지원한다.
## {{% heading "prerequisites" %}}
쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 `kubectl` 커맨드라인 툴을 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 한다. 이 섹션에서는 각 클러스터에 대해 한 번씩 필요한 일련의 초기 단계를 다룬다.
### GMSACredentialSpec CRD 설치
GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(CustomResourceDefinition,](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) CRD)을 클러스터에서 구성하여 사용자 정의 리소스 유형 `GMSACredentialSpec`을 정의해야 한다. GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)을 다운로드하고 gmsa-crd.yaml로 저장한다.
다음, `kubectl apply -f gmsa-crd.yaml` 로 CRD를 설치한다.
### GMSA 사용자를 검증하기 위해 웹훅 설치
쿠버네티스 클러스터에서 두 개의 웹훅을 구성하여 파드 또는 컨테이너 수준에서 GMSA 자격 증명 사양 참조를 채우고 검증한다.
1. 변형(mutating) 웹훅은 (파드 사양의 이름별로) GMSA에 대한 참조를 파드 사양 내 JSON 형식의 전체 자격 증명 사양으로 확장한다.
1. 검증(validating) 웹훅은 GMSA에 대한 모든 참조가 파드 서비스 어카운트에서 사용하도록 승인되었는지 확인한다.
위의 웹훅 및 관련 오브젝트를 설치하려면 다음 단계가 필요하다.
1. 인증서 키 쌍 생성 (웹훅 컨테이너가 클러스터와 통신할 수 있도록 하는데 사용됨)
1. 위의 인증서로 시크릿을 설치
1. 핵심 웹훅 로직에 대한 디플로이먼트(deployment)를 생성
1. 디플로이먼트를 참조하여 검증 및 변경 웹훅 구성을 생성
[스크립트](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)를 사용하여 GMSA 웹훅과 위에서 언급한 관련 오브젝트를 배포 및 구성할 수 있다. 스크립트는 ```--dry-run=server``` 옵션으로 실행되어 클러스터에 대한 변경 사항을 검토할 수 있다.
스크립트에서 사용하는 [YAML 템플릿](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)을 사용하여 웹훅 및 (파라미터를 적절히 대체하여) 관련 오브젝트를 수동으로 배포할 수도 있다.
<!-- steps -->
## 액티브 디렉터리에서 GMSA 및 윈도우 노드 구성
쿠버네티스의 파드가 GMSA를 사용하도록 구성되기 전에 [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)에 설명된 대로 액티브 디렉터리에서 원하는 GMSA를 프로비저닝해야 한다. [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)에 설명된 대로 원하는 GMSA와 연결된 시크릿 자격 증명에 접근하려면 (쿠버네티스 클러스터의 일부인) 윈도우 워커 노드를 액티브 디렉터리에서 구성해야 한다.
## GMSA 자격 증명 사양 리소스 생성
(앞에서 설명한 대로) GMSACredentialSpec CRD를 설치하면 GMSA 자격 증명 사양이 포함된 사용자 정의 리소스를 구성할 수 있다. GMSA 자격 증명 사양에는 시크릿 또는 민감한 데이터가 포함되어 있지 않다. 이것은 컨테이너 런타임이 원하는 윈도우 컨테이너 GMSA를 설명하는 데 사용할 수 있는 정보이다. GMSA 자격 증명 사양은 [PowerShell 스크립트](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 유틸리티를 사용하여 YAML 형식으로 생성할 수 있다.
다음은 JSON 형식으로 GMSA 자격 증명 사양 YAML을 수동으로 생성한 다음 변환하는 단계이다.
1. CredentialSpec [모듈](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1) 가져오기(import): `ipmo CredentialSpec.psm1`
1. `New-CredentialSpec`을 사용하여 JSON 형식의 자격 증명 사양을 만든다. WebApp1이라는 GMSA 자격 증명 사양을 만들려면 `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`를 호출한다.
1. `Get-CredentialSpec`을 사용하여 JSON 파일의 경로를 표시한다.
1. credspec 파일을 JSON에서 YAML 형식으로 변환하고 필요한 헤더 필드 `apiVersion`, `kind`, `metadata`, `credspec`을 적용하여 쿠버네티스에서 구성할 수 있는 GMSACredentialSpec 사용자 정의 리소스로 만든다.
다음 YAML 구성은 `gmsa-WebApp1`이라는 GMSA 자격 증명 사양을 설명한다.
```yaml
apiVersion: windows.k8s.io/v1alpha1
kind: GMSACredentialSpec
metadata:
name: gmsa-WebApp1 #임의의 이름이지만 참조로 사용된다.
credspec:
ActiveDirectoryConfig:
GroupManagedServiceAccounts:
- Name: WebApp1 #GMSA 계정의 사용자 이름
Scope: CONTOSO #NETBIOS 도메인 명
- Name: WebApp1 #GMSA 계정의 사용자 이름
Scope: contoso.com #DNS 도메인 명
CmsPlugins:
- ActiveDirectory
DomainJoinConfig:
DnsName: contoso.com #DNS 도메인 명
DnsTreeName: contoso.com #DNS 도메인 명 루트
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID
MachineAccountName: WebApp1 #GMSA 계정의 사용자 이름
NetBiosName: CONTOSO #NETBIOS 도메인 명
Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA
```
위의 자격 증명 사양 리소스는 `gmsa-Webapp1-credspec.yaml`로 저장되고 `kubectl apply -f gmsa-Webapp1-credspec.yml`을 사용하여 클러스터에 적용될 수 있다.
## 특정 GMSA 자격 증명 사양에서 RBAC를 활성화하도록 cluster role 구성
각 GMSA 자격 증명 사양 리소스에 대해 cluster role을 정의해야 한다. 이것은 일반적으로 서비스 어카운트인 주체에 의해 특정 GMSA 리소스에 대한 `use` 동사를 승인한다. 다음 예는 위에서 `gmsa-WebApp1` 자격 증명 사양의 사용을 승인하는 클러스터 롤(cluster role)을 보여준다. 파일을 gmsa-webapp1-role.yaml로 저장하고 `kubectl apply -f gmsa-webapp1-role.yaml`을 사용하여 적용한다.
```yaml
#credspec을 읽을 Role 생성
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
resources: ["gmsacredentialspecs"]
verbs: ["use"]
resourceNames: ["gmsa-WebApp1"]
```
## 특정 GMSA credspecs를 사용하도록 서비스 어카운트에 롤 할당
(파드가 사용하게 되는) 서비스 어카운트는 위에서 생성한 클러스터 롤에 바인딩되어야 한다. 이렇게 하면 서비스 어카운트가 원하는 GMSA 자격 증명 사양 리소스를 사용할 수 있다. 다음은 위에서 생성한 `gmsa-WebApp1` 자격 증명 사양 리소스를 사용하기 위해 `webapp1-role` 클러스터 롤에 바인딩되는 기본(default) 서비스 어카운트이다.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: allow-default-svc-account-read-on-gmsa-WebApp1
namespace: default
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: webapp1-role
apiGroup: rbac.authorization.k8s.io
```
## 파드 사양에서 GMSA 자격 증명 사양 참조 구성
파드 사양 필드 `securityContext.windowsOptions.gmsaCredentialSpecName`은 파드 사양에서 원하는 GMSA 자격 증명 사양 사용자 정의 리소스에 대한 참조를 지정하는 데 사용된다. 이렇게 하면 지정된 GMSA를 사용하도록 파드 사양의 모든 컨테이너가 구성된다. 다음은 `gmsa-WebApp1`을 참조하도록 채워진 어노테이션이 있는 샘플 파드 사양이다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
spec:
securityContext:
windowsOptions:
gmsaCredentialSpecName: gmsa-webapp1
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
nodeSelector:
kubernetes.io/os: windows
```
파드 사양의 개별 컨테이너는 컨테이너별 `securityContext.windowsOptions.gmsaCredentialSpecName` 필드를 사용하여 원하는 GMSA credspec을 지정할 수도 있다. 다음은 예이다.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: with-creds
name: with-creds
namespace: default
spec:
replicas: 1
selector:
matchLabels:
run: with-creds
template:
metadata:
labels:
run: with-creds
spec:
containers:
- image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
imagePullPolicy: Always
name: iis
securityContext:
windowsOptions:
gmsaCredentialSpecName: gmsa-Webapp1
nodeSelector:
kubernetes.io/os: windows
```
(위에서 설명한 대로) GMSA 필드가 채워진 파드 사양이 클러스터에 적용되면 다음과 같은 일련의 이벤트가 발생한다.
1. 변형 웹훅은 GMSA 자격 증명 사양 리소스에 대한 모든 참조를 확인하고 GMSA 자격 증명 사양의 내용으로 확장한다.
1. 검증 웹훅은 파드와 연결된 서비스 어카운트가 지정된 GMSA 자격 증명 사양의 `use` 동사에 대해 승인되었는지 확인한다.
1. 컨테이너 런타임은 컨테이너가 액티브 디렉터리에서 GMSA의 ID를 가정하고 해당 ID를 사용하여 도메인의 서비스에 접근할 수 있도록 지정된 GMSA 자격 증명 사양으로 각 윈도우 컨테이너를 구성한다.
## Containerd
윈도우 서버 2019에서 containerd와 함께 GMSA를 사용하려면 패치 [KB5000822](https://support.microsoft.com/ko-kr/topic/2021년-3월-9일-kb5000822-os-빌드-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564)된 OS Build 17763.1817 (또는 이후 버전)을 실행해야 한다.
또한 파드에서 SMB 공유에 연결하려고 할 때 발생하는 containerd와 관련된 알려진 문제가 있다. GMSA를 구성하면 파드가 hostname 또는 FQDN을 사용하여 공유에 연결할 수 없지만, IP 주소를 사용하여 공유에 연결하면 예상대로 작동한다.
```PowerShell
ping adserver.ad.local
```
hostname을 IPv4 주소로 올바르게 변환한다. 출력은 다음과 유사하다.
```
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
```
그러나 hostname을 사용하여 디렉터리를 탐색하려고 할 때
```PowerShell
cd \\adserver.ad.local\test
```
대상 공유가 존재하지 않음을 암시하는 오류가 표시된다.
```
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
At line:1 char:1
+ cd \\adserver.ad.local\test
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
```
그러나 IPv4 주소를 대신 사용하여 공유를 탐색하면 오류가 사라진다. 다음은 예시이다.
```PowerShell
cd \\192.168.111.18\test
```
공유 내의 디렉터리로 변경하면 다음과 유사한 프롬프트가 표시된다.
```
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
```
동작을 수정하려면 노드에서 `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1`을 실행하여 필요한 레지스트리 키를 추가해야 한다. 이 노드 변경 사항은 새로 생성된 파드에만 적용되는데, SMB 공유에 액세스해야 하는 실행 중인 파드를 다시 생성해야 하는 것을 의미한다.
## 문제 해결
GMSA가 사용자 환경에서 작동하도록 하는 데 어려움이 있는 경우 취할 수 있는 몇 가지 문제 해결 단계가 있다.
먼저 credspec이 파드에 전달되었는지 확인한다. 이렇게 하려면 파드 중 하나에서 `exec`를 실행하고 `nltest.exe /parentdomain` 명령의 출력을 확인해야 한다.
아래 예에서 파드는 credspec을 올바르게 가져오지 못했다.
```PowerShell
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
```
`nltest.exe /parentdomain` 는 다음과 같은 오류를 발생시킨다.
```
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
파드가 credspec을 올바르게 가져오면 다음으로 도메인과의 통신을 확인한다. 먼저 파드 내부에서 nslookup을 빠르게 수행하여 도메인의 루트를 찾는다.
이것은 다음의 세 가지를 의미한다.
1. 파드는 DC에 도달할 수 있다.
1. DC는 파드에 도달할 수 있다.
1. DNS가 올바르게 작동하고 있다.
DNS 및 통신 테스트를 통과하면 다음으로 파드가 도메인과 보안 채널 통신을 설정했는지 확인해야 한다. 이렇게 하려면 파드에서 다시 `exec`를 실행하고 `nltest.exe /query` 명령을 실행한다.
```PowerShell
nltest.exe /query
```
결과는 다음과 같다.
```
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
이것은 어떤 이유로 파드가 credspec에 지정된 계정을 사용하여 도메인에 로그온할 수 없음을 알려준다. 다음을 실행하여 보안 채널 복구를 시도할 수 있다.
```PowerShell
nltest /sc_reset:domain.example
```
명령이 성공하면 다음과 유사한 출력이 표시된다.
```
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully
```
위의 방법으로 오류가 수정되면 다음 수명 주기 훅(hook)을 파드 사양에 추가하여 단계를 자동화할 수 있다. 오류가 수정되지 않은 경우 credspec을 다시 검사하여 정확하고 완전한지 확인해야 한다.
```yaml
image: registry.domain.example/iis-auth:1809v1
lifecycle:
postStart:
exec:
command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
imagePullPolicy: IfNotPresent
```
위의 `lifecycle` 섹션을 파드 사양에 추가하면, 파드는 `nltest.exe /query` 명령이 오류 없이 종료될 때까지 나열된 명령을 실행하여 `netlogon` 서비스를 다시 시작한다.

2
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
View File

@ -102,7 +102,7 @@ kubectl create secret docker-registry regcred --docker-server=<your-registry-ser
아래의 각 항목에 대한 설명을 참고한다.
* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다.
도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다.
도커허브(DockerHub)는 `https://index.docker.io/v1/` 를 사용한다.
* `<your-name>` 은 도커 사용자의 계정이다.
* `<your-pword>` 은 도커 사용자의 비밀번호이다.
* `<your-email>` 은 도커 사용자의 이메일 주소이다.

7
content/ko/docs/tasks/configure-pod-container/static-pod.md
View File

@ -31,6 +31,13 @@ API 서버에서 제어될 수는 없다.
을 사용하는 것이 바람직하다.
{{< /note >}}
{{< note >}}
스태틱 파드의 `spec`은 다른 API 오브젝트(예를 들면,
{{< glossary_tooltip text="서비스어카운트" term_id="service-account" >}},
{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}},
{{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

43
content/ko/docs/tasks/debug-application-cluster/debug-stateful-set.md Normal file
View File

@ -0,0 +1,43 @@
---
title: 스테이트풀셋 디버깅하기
content_type: task
---
<!-- overview -->
이 문서에서는 스테이트풀셋을 디버깅 방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
* 쿠버네티스 클러스터가 준비되어 있어야 하고, kubectl 커맨드 라인 도구가 클러스터와 통신할 수 있게 사전에 설정되어 있어야 한다.
* 조사하고자 하는 스테이트풀셋이 사전에 준비되어 있어야 한다.
<!-- steps -->
## 스테이트풀셋 디버깅하기
레이블이 `app=myapp`으로 지정된 스테이트풀셋 파드를 전부 나열하기 위해서는
다음의 명령을 사용할 수 있다.
```shell
kubectl get pods -l app=myapp
```
만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
파드들을 발견하였다면, 이러한 파드들을 어떻게 다루는지 알아보기 위해
[스테이트풀셋 파드 삭제하기](/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
스테이트풀셋에 포함된 개별 파드들을 디버깅하기 위해서는
[파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) 가이드를 참고하길 바란다.
## {{% heading "whatsnext" %}}
[초기화 컨테이너(Init container) 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-init-containers/)를 참고길 바란다.

158
content/ko/docs/tasks/debug-application-cluster/get-shell-running-container.md Normal file
View File

@ -0,0 +1,158 @@
---
title: 동작중인 컨테이너의 셸에 접근하기
content_type: task
---
<!-- overview -->
이 페이지는 동작중인 컨테이너에 접근하기 위해 `kubectl exec`을 사용하는
방법에 대해 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 컨테이너의 셸에 접근하기
이 예시에서는 하나의 컨테이너를 가진 파드를 생성할 것이다. 이 컨테이너는
nginx 이미지를 실행한다. 해당 파드에 대한 설정 파일은 다음과 같다.
{{< codenew file="application/shell-demo.yaml" >}}
파드를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml
```
다음을 통해 컨테이너가 동작하고 있는지 확인할 수 있다.
```shell
kubectl get pod shell-demo
```
동작중인 컨테이너의 셸에 접근한다.
```shell
kubectl exec --stdin --tty shell-demo -- /bin/bash
```
{{< note >}}
kubectl 명령어 인자와 사용하고자 하는 명령어의 인자를 구분하기 위해서는 이중 대시(`--`)를 사용할 수 있다.
{{< /note >}}
셸에 접근해서 다음처럼 루트 디렉토리를 확인해 볼 수 있다.
```shell
# Run this inside the container
ls /
```
접근한 셸에서 다른 명령어도 한번 실행해 보아라. 다음은 실행해 볼
명령의 예시이다.
```shell
# You can run these example commands inside the container
ls /
cat /proc/mounts
cat /proc/1/maps
apt-get update
apt-get install -y tcpdump
tcpdump
apt-get install -y lsof
lsof
apt-get install -y procps
ps aux
ps aux | grep nginx
```
## nginx의 최상단 페이지 작성하기
앞에서 생성한 파드에 대한 설정을 살펴보아라. 파드에는
`emptyDir` 볼륨이 사용되었고, 이 컨테이너는 해당 볼륨을
`/usr/share/nginx/html` 경로에 마운트하였다.
접근한 셸 환경에서 `/usr/share/nginx/html` 디렉터리에 `index.html` 파일을
생성해 보아라.
```shell
# Run this inside the container
echo 'Hello shell demo' > /usr/share/nginx/html/index.html
```
셸 환경에서 nginx 서버에 GET 요청을 시도해보면 다음과 같다.
```shell
# Run this in the shell inside your container
apt-get update
apt-get install curl
curl http://localhost/
```
출력 결과는 여러분이 `index.html` 파일에 작성한 텍스트를 출력할 것이다.
```
Hello shell demo
```
셸 사용이 모두 끝났다면 `exit`을 입력해 종료하라.
```shell
exit # To quit the shell in the container
```
## 컨테이너에서 개별 명령어 실행하기
셸이 아닌 일반적인 커맨드 환경에서 다음처럼 동작중인 컨테이너의
환경 변수를 출력할 수 있다.
```shell
kubectl exec shell-demo env
```
다른 명령어도 한번 실행해 보아라. 다음은 실행해 볼 명령의 예시이다.
```shell
kubectl exec shell-demo -- ps aux
kubectl exec shell-demo -- ls /
kubectl exec shell-demo -- cat /proc/1/mounts
```
<!-- discussion -->
## 파드에 한 개 이상의 컨테이너가 있을 경우 셸에 접근하기
만일 파드에 한 개 이상의 컨테이너가 있을 경우, `kubectl exec` 명령어에
`--container` 혹은 `-c` 옵션을 사용해서 컨테이너를 지정하라. 예를 들어,
여러분이 my-pod라는 이름의 파드가 있다고 가정해 보자. 이 파드에는 _main-app_ 과
_helper-app_ 이라는 이름의 두 컨테이너가 있다. 다음 명령어는 _main-app_
컨테이너에 대한 셸에 접근할 것이다.
```shell
kubectl exec -i -t my-pod --container main-app -- /bin/bash
```
{{< note >}}
축약형 옵션인 `-i` 와 `-t` 는 각각 `--stdin` 와 `--tty` 옵션에 대응된다.
{{< /note >}}
## {{% heading "whatsnext" %}}
* [kubectl
* exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를참고한다.

88
content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md Normal file
View File

@ -0,0 +1,88 @@
---
title: Konnectivity 서비스 설정
content_type: task
weight: 70
---
<!-- overview -->
Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 TCP 수준 프록시를
제공한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## Konnectivity 서비스 설정
다음 단계에는 송신(egress) 설정이 필요하다. 예를 들면 다음과 같다.
{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록
API 서버를 구성해야 한다.
1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있는지
확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여
[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를
활성화할 수 있다.
```
--service-account-issuer=api
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
--api-audiences=system:konnectivity-server
```
1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다.
1. API 서버의 `--egress-selector-config-file` 플래그를
API 서버 송신 구성 파일의 경로로 설정한다.
1. UDS 연결을 사용하는 경우 kube-apiserver에 볼륨 구성을 추가한다.
```yaml
spec:
containers:
volumeMounts:
- name: konnectivity-uds
mountPath: /etc/kubernetes/konnectivity-server
readOnly: false
volumes:
- name: konnectivity-uds
hostPath:
path: /etc/kubernetes/konnectivity-server
type: DirectoryOrCreate
```
konnectivity-server에 대한 인증서 및 kubeconfig를 생성하거나 얻는다.
예를 들어 OpenSSL 커맨드라인 툴을 사용하여 컨트롤 플레인 호스트에서
클러스터 CA 인증서 `/etc/kubernetes/pki/ca.crt`를 사용하여 X.509 인증서를 발급할 수 있다.
```bash
openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
rm -f konnectivity.crt konnectivity.key konnectivity.csr
```
다음으로 Konnectivity 서버와 에이전트를 배포해야 한다.
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)에서
구현을 참조할 수 있다.
컨트롤 플레인 노드에 Konnectivity 서버를 배포한다. 제공된
`konnectivity-server.yaml` 매니페스트는
쿠버네티스 구성 요소가 클러스터에 {{< glossary_tooltip text="스태틱 파드(static Pod)"
term_id="static-pod" >}}로 배포되었다고 가정한다. 그렇지 않은 경우에는 Konnectivity
서버를 데몬셋(DaemonSet)으로 배포할 수 있다.
{{< codenew file="admin/konnectivity/konnectivity-server.yaml" >}}
그런 다음 클러스터에 Konnectivity 에이전트를 배포한다.
{{< codenew file="admin/konnectivity/konnectivity-agent.yaml" >}}
마지막으로 클러스터에서 RBAC가 활성화된 경우 관련 RBAC 규칙을 생성한다.
{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}

96
content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md Normal file
View File

@ -0,0 +1,96 @@
---
title: 스테이트풀셋(StatefulSet) 파드 강제 삭제하기
content_type: task
weight: 70
---
<!-- overview -->
이 페이지에서는 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}의 일부인 파드를 삭제하는 방법을 보여주고
이 과정에서 고려해야 할 사항을 설명한다.
## {{% heading "prerequisites" %}}
* 이것은 상당히 고급 태스크이며 스테이트풀셋 고유의 속성 중 일부를 위반할 가능성이 있다.
* 계속하기 전에 아래 나열된 고려 사항을 숙지하도록 한다.
<!-- steps -->
## 스테이트풀셋 고려 사항
정상적인 스테이트풀셋의 작동에서는 스테이트풀셋 파드를 강제로 삭제할 필요가 **절대** 없다. [스테이트풀셋 컨트롤러](/ko/docs/concepts/workloads/controllers/statefulset/)는 스테이트풀셋의 멤버 생성, 스케일링, 삭제를 담당한다. 서수 0부터 N-1까지 지정된 수의 파드가 활성 상태이고 준비되었는지 확인한다. 스테이트풀셋은 언제든지 클러스터에서 실행 중인 지정된 신원을 가진 최대 하나의 파드가 있는지 확인한다. 이를 스테이트풀셋에서 제공하는 *최대 하나* 의미론이라고 한다.
수동 강제 삭제는 스테이트풀셋 고유의 최대 하나 의미론을 위반할 가능성이 있으므로 주의해서 수행해야 한다. 스테이트풀셋은 안정적인 네트워크 신원과 안정적인 스토리지가 필요한 분산 클러스터 애플리케이션을 실행하는 데 사용할 수 있다. 이러한 애플리케이션은 종종 고정된 신원을 가진 고정된 수의 구성원 앙상블에 의존하는 구성을 가진다. 여러 구성원이 동일한 신원을 갖는 것은 재앙이 될 수 있으며 데이터 손실로 이어질 수 있다(예: 쿼럼 기반 시스템의 스플릿 브레인(split-brain) 시나리오).
## 파드 삭제
다음 명령을 사용하여 파드를 단계적으로 삭제할 수 있다.
```shell
kubectl delete pods <pod>
```
위의 내용이 단계적인 종료로 이어지려면 파드가
`pod.Spec.TerminationGracePeriodSeconds`를 0으로 지정하지 **않아야 한다**.
`pod.Spec.TerminationGracePeriodSeconds`를 0초로 설정하는 관행은 안전하지 않으며
스테이트풀셋 파드에서 강력히 권장하지 않는다. 단계적 삭제는 안전하며 kubelet이 apiserver에서 이름을 삭제하기 전에 파드가
[정상적으로 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)되도록 한다.
노드에 연결할 수 없는 경우 파드는 자동으로 삭제되지 않는다.
연결할 수 없는 노드에서 실행 중인 파드는 [타임아웃](/ko/docs/concepts/architecture/nodes/#condition) 후에
'Terminating'이나 'Unknown' 상태가 된다.
사용자가 연결할 수 없는 노드에서 파드를 단계적으로 삭제하려고 하면 파드가 이러한 상태에 들어갈 수도 있다.
이러한 상태의 파드를 apiserver에서 제거할 수 있는 유일한 방법은 다음과 같다.
* 노드 오브젝트가 삭제된다(사용자 또는 [노드 컨트롤러](/ko/docs/concepts/architecture/nodes/)에 의해).
* 응답하지 않는 노드의 kubelet이 응답을 시작하고 파드를 종료하여 apiserver에서 항목을 제거한다.
* 사용자가 파드를 강제로 삭제한다.
권장되는 모범 사례는 첫 번째 또는 두 번째 방법을 사용하는 것이다. 노드가 죽은 것으로 확인되면(예: 네트워크에서 영구적으로 연결이 끊기거나 전원이 꺼진 경우 등) 노드 오브젝트를 삭제한다. 노드에 네트워크 파티션이 있는 경우 이를 해결하거나 해결될 때까지 기다린다. 파티션이 복구되면 kubelet은 파드 삭제를 완료하고 apiserver에서 해당 이름을 해제한다.
일반적으로 시스템은 파드가 노드에서 더 이상 실행되지 않거나 노드가 관리자에 의해 삭제되면 삭제를 완료한다. 파드를 강제로 삭제하여 이를 재정의할 수 있다.
### 강제 삭제
강제 삭제는 파드가 종료되었다는 kubelet의 확인을 기다리지 **않는다**. 강제 삭제가 파드를 죽이는 데 성공했는지 여부와 관계없이 즉시 apiserver에서 이름을 해제한다. 이렇게 하면 스테이트풀셋 컨트롤러가 동일한 신원으로 대체 파드를 생성할 수 있다. 이것은 여전히 실행 중인 파드와 중복될 수 있으며, 해당 파드가 여전히 스테이트풀셋의 다른 멤버와 통신할 수 있다면 스테이트풀셋이 보장하도록 설계된 최대 하나 의미론을 위반할 것이다.
스테이트풀셋 파드를 강제로 삭제하는 것은 문제의 파드가 스테이트풀셋의 다른 파드와 다시는 접촉하지 않으며 대체 생성을 위해 해당 이름을 안전하게 해제할 수 있다고 주장하는 것이다.
kubectl 버전 >= 1.5를 사용하여 파드를 강제로 삭제하려면, 다음을 수행한다.
```shell
kubectl delete pods <pod> --grace-period=0 --force
```
kubectl <= 1.4 버전을 사용하는 경우, `--force` 옵션을 생략하고 다음을 사용해야 한다.
```shell
kubectl delete pods <pod> --grace-period=0
```
이러한 명령 후에도 파드가 `Unknown` 상태에서 멈추면, 다음 명령을 사용하여 클러스터에서 파드를 제거한다.
```shell
kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
```
항상 관련된 위험에 대해 완전히 이해한 상태에서 주의 깊게 스테이트풀셋 파드의 강제 삭제를 수행한다.
## {{% heading "whatsnext" %}}
[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.

20
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -1,4 +1,9 @@
---
title: Horizontal Pod Autoscaler 연습
content_type: task
weight: 100
@ -100,7 +105,8 @@ NAME REFERENCE TARGET MINPODS MAXPODS REPLICA
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
```
아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다 (``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다).
아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다.
(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다)
## 부하 증가
@ -236,15 +242,11 @@ CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원
더 고급화된 클러스터 모니터링 설정이 필요하다.
이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다.
이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며,
대상 값과 비교하여 레플리카 개수를 결정한다.
이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면,
자원 메트릭과 매우 유사하게 동작한다.
이 메트릭은 파드들을 설명하고, 파드들 간의 평균을 내며, 대상 값과 비교하여 레플리카 개수를 결정한다.
이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, 자원 메트릭과 매우 유사하게 동작한다.
파드 메트릭은 이처럼 메트릭 블록을 사용하여 정의된다.
```yaml
type: Pods
pods:
@ -395,7 +397,9 @@ object:
external:
metric:
name: queue_messages_ready
selector: "queue=worker_tasks"
selector:
matchLabels:
queue: "worker_tasks"
target:
type: AverageValue
averageValue: 30

14
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -68,14 +68,7 @@ Horizontal Pod Autoscaler는 컨트롤러
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
[메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="v1.11" >}}
힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨.
{{< /note >}}
시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다.
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다.
@ -225,8 +218,7 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
안정화되기까지의 시간 간격을 지정한다.
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
이 시간 간격에서의 가장 큰 크기에서만 작동한다.
기본값은 5분(`5m0s`)이다.
이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다.
{{< note >}}
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
@ -345,8 +337,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
* `--horizontal-pod-autoscaler-use-rest-clients`는 `true`이거나 설정되지 않음. 이것을 false로 설정하면 더 이상 사용되지 않는 힙스터 기반 오토스케일링으로 전환된다.
이런 다양한 메트릭 경로와 각각의 다른 점에 대한 상세 내용은 관련 디자인 제안서인
[HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md),

1
content/ko/docs/tutorials/_index.md
View File

@ -51,6 +51,7 @@ content_type: concept
* [AppArmor](/ko/docs/tutorials/clusters/apparmor/)
* [seccomp](/docs/tutorials/clusters/seccomp/)
## 서비스
* [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/)

12
content/ko/docs/tutorials/hello-minikube.md
View File

@ -24,8 +24,6 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
설치 안내는 [minikube 시작](https://minikube.sigs.k8s.io/docs/start/)을 참고한다.
{{< /note >}}
## {{% heading "objectives" %}}
* 샘플 애플리케이션을 minikube에 배포한다.
@ -62,16 +60,22 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭.
{{< note >}}
`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다. 대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다.
`minikube dashboard` 명령을 내리면 대시보드 애드온과 프록시가 활성화되고 해당 프록시로 접속하는 기본 웹 브라우저 창이 열린다.
대시보드에서 디플로이먼트나 서비스와 같은 쿠버네티스 자원을 생성할 수 있다.
root 환경에서 명령어를 실행하고 있다면, [URL을 이용하여 대시보드 접속하기](#open-dashboard-with-url)를 참고한다.
기본적으로 대시보드는 쿠버네티스 내부 가상 네트워크 안에서만 접근할 수 있다.
`dashboard` 명령은 쿠버네티스 가상 네트워크 외부에서 대시보드에 접근할 수 있도록 임시 프록시를 만든다.
`Ctrl+C` 를 눌러 프록시를 종료할 수 있다. 대시보드는 종료되지 않고 실행 상태로 남아 있다.
명령이 종료된 후 대시보드는 쿠버네티스 클러스터에서 계속 실행된다.
`dashboard` 명령을 다시 실행하여 대시보드에 접근하기 위한 다른 프록시를 생성할 수 있다.
{{< /note >}}
## URL을 이용하여 대시보드 접속하기 {#open-dashboard-with-url}
자동으로 웹 브라우저가 열리는 것을 원치 않는다면, 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다:
자동으로 웹 브라우저가 열리는 것을 원치 않는다면, `--url` 플래그와 함께 다음과 같은 명령어를 실행하여 대시보드 접속 URL을 출력할 수 있다.
```shell
minikube dashboard --url

8
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -1,5 +1,11 @@
---
reviewers:
title: 스테이트풀셋 기본
content_type: tutorial
weight: 10

8
content/ko/docs/tutorials/stateful-application/zookeeper.md
View File

@ -1,4 +1,12 @@
---
title: 분산 시스템 코디네이터 ZooKeeper 실행하기
content_type: tutorial
weight: 40

20
content/ko/examples/admin/konnectivity/egress-selector-configuration.yaml Normal file
View File

@ -0,0 +1,20 @@
apiVersion: apiserver.k8s.io/v1beta1
kind: EgressSelectorConfiguration
egressSelections:
# 클러스터에 대한 송신(egress) 트래픽을 제어하기 위해
# "cluster"를 name으로 사용한다. 기타 지원되는 값은 "etcd" 및 "master"이다.
- name: cluster
connection:
# API 서버와 Konnectivity 서버 간의 프로토콜을
# 제어한다. 지원되는 값은 "GRPC" 및 "HTTPConnect"이다. 두 모드 간에
# 최종 사용자가 볼 수 있는 차이점은 없다. 동일한 모드에서 작동하도록
# Konnectivity 서버를 설정해야 한다.
proxyProtocol: GRPC
transport:
# API 서버가 Konnectivity 서버와 통신하는 데 사용하는
# transport를 제어한다. Konnectivity 서버가 API 서버와 동일한 시스템에
# 있는 경우 UDS를 사용하는 것이 좋다. 동일한 UDS 소켓에서
# 수신 대기하도록 Konnectivity 서버를 구성해야 한다.
# 지원되는 다른 전송은 "tcp"이다. TCP 전송을 보호하려면 TLS 구성을 설정해야 한다.
uds:
udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket

55
content/ko/examples/admin/konnectivity/konnectivity-agent.yaml Normal file
View File

@ -0,0 +1,55 @@
apiVersion: apps/v1
# 에이전트를 Deployment(디플로이먼트)로 배포할 수도 있다. 각 노드에 에이전트가
# 있을 필요는 없다.
kind: DaemonSet
metadata:
labels:
addonmanager.kubernetes.io/mode: Reconcile
k8s-app: konnectivity-agent
namespace: kube-system
name: konnectivity-agent
spec:
selector:
matchLabels:
k8s-app: konnectivity-agent
template:
metadata:
labels:
k8s-app: konnectivity-agent
spec:
priorityClassName: system-cluster-critical
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.16
name: konnectivity-agent
command: ["/proxy-agent"]
args: [
"--logtostderr=true",
"--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
# konnectivity 서버는 hostNetwork=true로 실행되기 때문에,
# 이것은 마스터 머신의 IP 주소이다.
"--proxy-server-host=35.225.206.7",
"--proxy-server-port=8132",
"--admin-server-port=8133",
"--health-server-port=8134",
"--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
]
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: konnectivity-agent-token
livenessProbe:
httpGet:
port: 8134
path: /healthz
initialDelaySeconds: 15
timeoutSeconds: 15
serviceAccountName: konnectivity-agent
volumes:
- name: konnectivity-agent-token
projected:
sources:
- serviceAccountToken:
path: konnectivity-agent-token
audience: system:konnectivity-server

24
content/ko/examples/admin/konnectivity/konnectivity-rbac.yaml Normal file
View File

@ -0,0 +1,24 @@
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:konnectivity-server
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: system:konnectivity-server
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: konnectivity-agent
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile

72
content/ko/examples/admin/konnectivity/konnectivity-server.yaml Normal file
View File

@ -0,0 +1,72 @@
apiVersion: v1
kind: Pod
metadata:
name: konnectivity-server
namespace: kube-system
spec:
priorityClassName: system-cluster-critical
hostNetwork: true
containers:
- name: konnectivity-server-container
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16
command: ["/proxy-server"]
args: [
"--logtostderr=true",
# 이것은 egressSelectorConfiguration에 설정된 값과 일치해야 한다.
"--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
# 다음 두 줄은 Konnectivity 서버가 apiserver와
# 동일한 시스템에 배포되고 API 서버의 인증서와
# 키가 지정된 위치에 있다고 가정한다.
"--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
"--cluster-key=/etc/kubernetes/pki/apiserver.key",
# 이것은 egressSelectorConfiguration에 설정된 값과 일치해야 한다.
"--mode=grpc",
"--server-port=0",
"--agent-port=8132",
"--admin-port=8133",
"--health-port=8134",
"--agent-namespace=kube-system",
"--agent-service-account=konnectivity-agent",
"--kubeconfig=/etc/kubernetes/konnectivity-server.conf",
"--authentication-audience=system:konnectivity-server"
]
livenessProbe:
httpGet:
scheme: HTTP
host: 127.0.0.1
port: 8134
path: /healthz
initialDelaySeconds: 30
timeoutSeconds: 60
ports:
- name: agentport
containerPort: 8132
hostPort: 8132
- name: adminport
containerPort: 8133
hostPort: 8133
- name: healthport
containerPort: 8134
hostPort: 8134
volumeMounts:
- name: k8s-certs
mountPath: /etc/kubernetes/pki
readOnly: true
- name: kubeconfig
mountPath: /etc/kubernetes/konnectivity-server.conf
readOnly: true
- name: konnectivity-uds
mountPath: /etc/kubernetes/konnectivity-server
readOnly: false
volumes:
- name: k8s-certs
hostPath:
path: /etc/kubernetes/pki
- name: kubeconfig
hostPath:
path: /etc/kubernetes/konnectivity-server.conf
type: FileOrCreate
- name: konnectivity-uds
hostPath:
path: /etc/kubernetes/konnectivity-server
type: DirectoryOrCreate

16
content/ko/examples/application/shell-demo.yaml Normal file
View File

@ -0,0 +1,16 @@
apiVersion: v1
kind: Pod
metadata:
name: shell-demo
spec:
volumes:
- name: shared-data
emptyDir: {}
containers:
- name: nginx
image: nginx
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
hostNetwork: true
dnsPolicy: Default

18
content/ko/examples/service/networking/example-ingress.yaml Normal file
View File

@ -0,0 +1,18 @@
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: hello-world.info
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 8080