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

Merge pull request #30600 from kubernetes/dev-1.21-ko.8 

[ko] 8th Korean localization work for release-1.21
pull/30767/head
Kubernetes Prow Robot 2021-11-22 19:10:16 -08:00 committed by GitHub
parent df6cb680e7 4dd537066d
commit 722543fcb2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
53 changed files with 337 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/ko/community/_index.html
View File

@ -12,8 +12,8 @@ cid: community
<div class="intro">
<br class="mobile">
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다.
<br><br>우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, <code>kubectl get pods</code> 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
<br><br>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, <code>kubectl get pods</code> 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
<br class="mobile">
</div>

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

@ -363,19 +363,19 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `ShutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.

2
content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
View File

@ -93,5 +93,5 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
## {{% heading "whatsnext" %}}
자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
본다.

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

@ -12,26 +12,33 @@ weight: 30
<!-- overview -->
쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이
{{< glossary_tooltip term_id="pod" >}} 정의나
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
내에 그대로 두는 것보다 안전하고 유연하다.
자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
일부 시크릿을 만들 수 있다.
포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
애플리케이션 코드에 넣을 필요가
없음을 뜻한다.
시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
특별히 기밀 데이터를 보관하기 위한 것이다.
{{< caution >}}
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
활성화 또는 구성.
3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
{{< /caution >}}
<!-- body -->
@ -47,6 +54,10 @@ weight: 30
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@ -407,9 +418,9 @@ stringData:
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
- [`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/)
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
## 시크릿 편집하기
@ -1236,9 +1247,8 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
시크릿을 노출하는 파드를 실행할 수 있다.
## {{% heading "whatsnext" %}}
- [`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/)하는 방법 배우기
- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기

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

@ -1,4 +1,7 @@
---
title: 이미지
content_type: concept
weight: 10
@ -16,9 +19,6 @@ weight: 10
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
<!-- body -->
## 이미지 이름
@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
### 미리 내려받은 이미지
{{< note >}}
Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
{{< /note >}}
{{< note >}}
이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
## {{% heading "whatsnext" %}}
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.

5
content/ko/docs/concepts/containers/runtime-class.md
View File

@ -1,4 +1,7 @@
---
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
유효한 핸들러는 runtimes 단락 아래에서 설정한다.
```
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
더 자세한 containerd의 구성 문서를 살펴본다.

2
content/ko/docs/concepts/overview/what-is-kubernetes.md
View File

@ -45,7 +45,7 @@ sitemap:
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.

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

@ -30,6 +30,11 @@ weight: 50
}
```
{{<note>}}
맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
{{</note>}}
다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은

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

@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
## 구문과 캐릭터 셋
@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하여야 하고 (공백일 수도 있음),
* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
```yaml
@ -97,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
{{< /note >}}
{{< caution >}}
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.
{{< /caution >}}
### _일치성 기준_ 요건
@ -233,7 +231,7 @@ selector:
- {key: environment, operator: NotIn, values: [dev]}
```
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.
#### 노드 셋 선택

18
content/ko/docs/concepts/overview/working-with-objects/names.md
View File

@ -1,4 +1,7 @@
---
title: 오브젝트 이름과 ID
content_type: concept
weight: 20
@ -25,7 +28,7 @@ weight: 20
물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
{{< /note >}}
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름
@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### DNS 레이블 이름
### RFC 1123 레이블 이름 {#dns-label-names}
일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
정의된 대로 DNS 레이블 표준을 따라야 한다.
@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### RFC 1035 레이블 이름
몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
정의된 DNS 레이블 표준을 따르도록 요구한다.
이것은 이름이 다음을 만족해야 한다는 의미이다.
- 최대 63개 문자를 포함
- 소문자 영숫자 또는 '-'만 포함
- 알파벳 문자로 시작
- 영숫자로 끝남
### 경로 세그먼트 이름
일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수

27
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -1,4 +1,7 @@
---
title: 파드 우선순위(priority)와 선점(preemption)
content_type: concept
weight: 70
@ -350,21 +353,25 @@ spec:
`PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
축출 대상으로 고려한다.
QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
먼저 축출 대상 파드의 순위를 매긴다.
더 자세한 내용은
[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다.
사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부
1. 파드 우선순위
1. 요청 대비 리소스 사용량
더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
참조한다.
kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
더 높은 다른 파드가 축출될 수 있다.
## {{% heading "whatsnext" %}}
* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)
* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다.
* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다.
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다.

6
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -264,10 +264,10 @@ tolerations:
이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
## 컨디션을 기준으로 노드 테인트하기
## 조건(condition)을 기준으로 노드 테인트하기
컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여
[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
@ -298,5 +298,5 @@ tolerations:
## {{% heading "whatsnext" %}}
* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기

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

@ -32,6 +32,7 @@ weight: 40
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의

2
content/ko/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기
* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

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

@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-레이블-이름)이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@ -188,7 +188,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.

25
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -76,7 +76,7 @@ volumeBindingMode: Immediate
| Glusterfs | &#x2713; | [Glusterfs](#glusterfs) |
| iSCSI | - | - |
| Quobyte | &#x2713; | [Quobyte](#quobyte) |
| NFS | - | - |
| NFS | - | [NFS](#nfs) |
| RBD | &#x2713; | [Ceph RBD](#ceph-rbd) |
| VsphereVolume | &#x2713; | [vSphere](#vsphere) |
| PortworxVolume | &#x2713; | [Portworx 볼륨](#portworx-볼륨) |
@ -423,6 +423,29 @@ parameters:
헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
### NFS
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: example-nfs
provisioner: example.com/external-nfs
parameters:
server: nfs-server.example.com
path: /share
readOnly: false
```
* `server`: NFS 서버의 호스트네임 또는 IP 주소.
* `path`: NFS 서버가 익스포트(export)한 경로.
* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
예시는 다음과 같다.
* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
### OpenStack Cinder
```yaml

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

@ -255,7 +255,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
## 잡의 종료와 정리
잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면
잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.
이를 유지하면
완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
`kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.

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

@ -282,6 +282,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
## 컨테이너 프로브
_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
- `TCPSocketAction` (kubelet에 의해 직접 검사)
- `HTTPGetAction` (kubelet에 의해 직접 검사)
[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
파드 라이프사이클 문서를 참고한다.
## {{% heading "whatsnext" %}}
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.

2
content/ko/docs/concepts/workloads/pods/disruptions.md
View File

@ -31,7 +31,7 @@ weight: 60
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면

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

@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
다음의 규칙이 적용된다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
높은 것은 *유효한 초기화 요청량/상한* 이다.
* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중
가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는
이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
* 리소스에 대한 유효한 초기화 요청량/상한

2
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
프로세스를 시작한다.
1. 파드의 컨테이너 중 하나가 `preStop`
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
[훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)을 정의한 경우, kubelet은
컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
요청한다.

15
content/ko/docs/contribute/generate-ref-docs/quickstart.md
View File

@ -6,7 +6,7 @@ weight: 40
<!-- overview -->
이 문서에서는 `update-imported-docs` 스크립트를 사용하여
이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여
쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다.
이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
@ -39,7 +39,7 @@ git clone git@github.com:<your_github_username>/website.git
## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/`
`update-imported-docs.py` 스크립트는 `<web-base>/update-imported-docs/`
디렉터리에 존재한다.
이 스크립트는 다음 레퍼런스를 생성한다.
@ -48,7 +48,7 @@ git clone git@github.com:<your_github_username>/website.git
* `kubectl` 명령어 레퍼런스
* 쿠버네티스 API 레퍼런스
`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를
생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와
`kubernetes-sigs/reference-docs` 저장소를 클론하며,
@ -69,7 +69,7 @@ git clone git@github.com:<your_github_username>/website.git
`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
1. 환경설정 파일에 있는 관련 저장소를 클론한다.
레퍼런스 문서 생성을 위해
@ -152,17 +152,17 @@ repos:
## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
```shell
cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version>
./update-imported-docs.py <configuration-file.yml> <release-version>
```
예를 들면 다음과 같다.
```shell
./update-imported-docs reference.yml 1.17
./update-imported-docs.py reference.yml 1.17
```
<!-- Revisit: is the release configuration used -->
@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)

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

@ -1,7 +1,10 @@
---
weight: 10
title: 기능 게이트
weight: 10
content_type: concept
card:
name: reference
weight: 60
---
<!-- overview -->
@ -640,7 +643,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
[퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,

2
content/ko/docs/reference/glossary/api-eviction.md
View File

@ -2,7 +2,7 @@
title: API를 이용한 축출(Eviction)
id: api-eviction
date: 2021-04-27
full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/
short_description: >
API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
축출 오브젝트를 만드는 프로세스이다

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

@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags]
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.

3
content/ko/docs/reference/labels-annotations-taints.md
View File

@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
## experimental.windows.kubernetes.io/isolation-type
## experimental.windows.kubernetes.io/isolation-type (사용 중단됨) {#experimental-windows-kubernetes-io-isolation-type}
예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려
{{< note >}}
이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다.
{{< /note >}}
## ingressclass.kubernetes.io/is-default-class

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

@ -8,7 +8,7 @@ no_list: true
---
<!-- overview -->
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
<!-- body -->

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

@ -1,5 +1,7 @@
---
title: 쿠버네티스 API 헬스(health) 엔드포인트
content_type: concept
weight: 50
---
@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
{{< feature-state state="alpha" >}}
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

6
content/ko/docs/setup/best-practices/cluster-large.md
View File

@ -1,4 +1,7 @@
---
title: 대형 클러스터에 대한 고려 사항
weight: 20
---
@ -121,3 +124,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
노드 수를 실행할 수 있도록 도와준다.
[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는
클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.

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

@ -31,6 +31,7 @@ card:
<!-- steps -->
## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address}
* 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
* product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다.
@ -239,8 +240,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
```bash
CNI_VERSION="v0.8.2"
ARCH="amd64"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
```
명령어 파일을 다운로드할 디렉터리 정의
@ -259,15 +261,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에
```bash
CRICTL_VERSION="v1.17.0"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```
`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
```bash
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}
RELEASE_VERSION="v0.4.0"

21
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -1,4 +1,9 @@
---
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
content_type: concept
weight: 75
@ -20,8 +25,8 @@ weight: 75
## 시작하기 전에
* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
포함한 쿠버네티스 클러스터를 생성한다.
* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
포함하는 쿠버네티스 클러스터를 생성한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
모두 비슷한 방식이라는 것이 중요하다.
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
@ -100,15 +105,15 @@ spec:
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
* 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
* 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
* 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
* 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
* 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
* 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
* 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
* 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
{{< note >}}
@ -178,8 +183,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
예를 들면, `--register-with-taints='os=windows:NoSchedule'`
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
윈도우 파드가 윈도우 노드에 스케줄링되려면,
윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
```yaml
nodeSelector:

4
content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
View File

@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
```
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
```
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.

15
content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
View File

@ -1,4 +1,9 @@
---
title: 윈도우 노드 추가
min-kubernetes-server-version: 1.17
content_type: tutorial
@ -157,10 +162,10 @@ Install-WindowsFeature -Name containers
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
```PowerShell
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
#### `kubeadm` 실행하여 노드에 조인
@ -201,7 +206,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
#### wins, kubelet 및 kubeadm 설치
```PowerShell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```

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

@ -126,7 +126,18 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로
kubectl을 사용하여 삭제 및 재시작할 수 없다.
스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고
20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/
reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
{{< warning >}}
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.

66
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,18 +74,18 @@ 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 >}}
@ -120,13 +120,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.
```
@ -171,20 +171,20 @@ sudo kubeadm upgrade apply
{{< tabs name="k8s_install_kubelet" >}}
{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
<pre>>
# {{< 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
</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
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
</pre>
{{< /tab >}}
{{< /tabs >}}
@ -216,18 +216,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,18 +254,18 @@ 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 >}}

66
content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
View File

@ -1,4 +1,7 @@
---
title: 네트워크 폴리시로 실리움(Cilium) 사용하기
content_type: task
weight: 20
@ -22,44 +25,59 @@ weight: 20
실리움에 쉽게 친숙해지기 위해
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
Minikube를 시작하려면 최소 버전으로 >= v1.5.2 가 필요하고,
다음의 실행 파라미터로 실행한다.
```shell
minikube version
```
```
minikube version: v1.3.1
minikube version: v1.5.2
```
```shell
minikube start --network-plugin=cni --memory=4096
minikube start --network-plugin=cni
```
BPF 파일시스템을 마운트한다
minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
실리움은 클러스터 구성을 자동으로 감지하고
성공적인 설치를 위해 적절한 구성 요소를 설치한다.
```shell
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz
cilium install
```
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
```shell
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
```
```
configmap/cilium-config created
serviceaccount/cilium created
serviceaccount/cilium-operator created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium create
deployment.apps/cilium-operator created
🔮 Auto-detected Kubernetes kind: minikube
✨ Running "minikube" validation checks
✅ Detected minikube version "1.20.0"
ℹ️ Cilium version not set, using default version "v1.10.0"
🔮 Auto-detected cluster name: minikube
🔮 Auto-detected IPAM mode: cluster-pool
🔮 Auto-detected datapath mode: tunnel
🔑 Generating CA...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
🔑 Generating certificates for Hubble...
2021/05/27 02:54:44 [INFO] generate received request
2021/05/27 02:54:44 [INFO] received CSR
2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
2021/05/27 02:54:44 [INFO] encoded CSR
2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed...
```
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
@ -82,14 +100,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
파드의 목록을 보려면 다음을 실행한다.
```shell
kubectl get pods --namespace=kube-system
kubectl get pods --namespace=kube-system -l k8s-app=cilium
```
다음과 유사한 파드의 목록을 볼 것이다.
```console
NAME READY STATUS RESTARTS AGE
cilium-6rxbd 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE
cilium-kkdhz 1/1 Running 0 3m23s
...
```

2
content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
View File

@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
다음 커맨드를 실행한다.
```shell
kubectl create secret generic dev-db-secret \
kubectl create secret generic db-user-pass \
--from-literal=username=devuser \
--from-literal=password='S!B\*d$zDsb='
```

4
content/ko/docs/tasks/manage-daemon/update-daemon-set.md
View File

@ -11,6 +11,8 @@ weight: 10
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 데몬셋 업데이트 전략
@ -143,7 +145,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out
#### 일부 노드에 리소스가 부족하다
적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이
중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
중단되었다. 노드에 [리소스가 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
발생할 수 있다.
이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여

2
content/ko/docs/tasks/network/validate-dual-stack.md
View File

@ -16,7 +16,7 @@ content_type: task
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet)
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
{{< version-check >}}

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

@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
```shell
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
```
에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.

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

@ -1,4 +1,8 @@
---
title: Horizontal Pod Autoscaler
feature:
title: Horizontal 스케일링
@ -9,10 +13,6 @@ content_type: concept
weight: 90
---
<!-- overview -->
Horizontal Pod Autoscaler는 CPU 사용량
@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
## kubectl에서 Horizontal Pod Autoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
## 롤링 업데이트 중 오토스케일링
현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다.
이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다.
디플로이먼트에 오토스케일링을 설정하려면,
각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다.
HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다.
디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여
롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면,
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
레플리카셋과 같은 중간 리소스가 없다).
## 쿨-다운 / 지연에 대한 지원

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

@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
```bash
sudo mv ./kubectl /usr/local/bin/kubectl-convert
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
```

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

@ -346,16 +346,21 @@ Events:
[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
{{< note >}}
파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다.
더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
{{< /note >}}
만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
```
--enable-admission-plugins=PodSecurityPolicy[,others...]
```
AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
```yaml
apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
@ -385,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
파드의 권한을 docker-default 보다 높일 수 있다.
이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
@ -434,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
### 프로파일 참조 {#profile-reference}
- `runtime/default`: 기본 런타임 프로파일을 참조한다.
- (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
- (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
AppArmor를 사용하는 것과 동등하다.
- 도커에서는 권한 없는 컨테이너의 경우는
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
@ -446,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
다른 어떤 프로파일 참조 형식도 유효하지 않다.
### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기

2
content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
View File

@ -26,7 +26,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">모듈 2로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">모듈 2로 진행하기 &gt;<span class=""></span></a>
</div>
</div>

4
content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
View File

@ -37,9 +37,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt 모듈 1로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt; 모듈 1로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">모듈 3으로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">모듈 3으로 진행하기 &gt;<span class=""></span></a>
</div>
</div>

4
content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
View File

@ -29,9 +29,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt 모듈 2로 돌아가기<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt; 모듈 2로 돌아가기<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">모듈 4로 진행하기 &gt<span class="btn"></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">모듈 4로 진행하기 &gt;<span class="btn"></span></a>
</div>
</div>

4
content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
View File

@ -26,9 +26,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt 모듈 3으로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt; 모듈 3으로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">모듈 5로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">모듈 5로 진행하기 &gt;<span class=""></span></a>
</div>
</div>

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

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

4
content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
View File

@ -26,9 +26,9 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt 모듈 4로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt; 모듈 4로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">홈으로 이동<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">모듈 6으로 진행하기 &gt<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">모듈 6으로 진행하기 &gt;<span class=""></span></a>
</div>
</div>

2
content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html
View File

@ -26,7 +26,7 @@ weight: 20
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt 모듈 5로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt; 모듈 5로 돌아가기<span class=""></span></a>
<a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/" role="button">쿠버네티스 기초로 돌아가기<span class=""></span></a>
</div>
</div>

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

@ -50,7 +50,7 @@ weight: 30
### 추가적인 Minikube 설정 요령
{{< caution >}}
[Minikube](https://minikube.sigs.k8s.io/docs/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다.
[Minikube](https://minikube.sigs.k8s.io/docs/)는 2048MB 메모리와 2개 CPU가 기본 설정이다.
이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가
발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.

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

@ -19,7 +19,7 @@ weight: 40
- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/)
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@ -929,7 +929,7 @@ kubernetes-node-i4c4
[`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자.
```shell
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
```
@ -964,7 +964,7 @@ zk-0 1/1 Running 0 1m
`zk-1` 이 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
```
```
@ -1007,7 +1007,7 @@ zk-1 0/1 Pending 0 0s
`zk-2`가 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
```
@ -1094,7 +1094,7 @@ zk-1 1/1 Running 0 13m
`zk-2`가 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
```
출력은

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

@ -19,7 +19,7 @@ _(운영 수준이 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고
이 예제는 다음과 같은 구성으로
이루어져 있다.
* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.com/)
* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.io/)
* 여러 개의 웹 프론트엔드 인스턴스
## {{% heading "objectives" %}}