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

Ko: Third Korean l10n work for release-1.20 

- Update outdated files in the dev-1.20-ko.3 (1) (#26131)
- Update outdated files in the dev-1.20-ko.3 branch (2) (#26122)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
pull/26277/head
seokho-son 2021-01-18 15:46:35 +09:00 committed by June Yi
parent 8cf053698d
commit 05da4dd669
46 changed files with 354 additions and 213 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
View File

@ -70,7 +70,7 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.
참고할 사항 한 가지: 현재 클러스터 내 워크플로의 일부가 기본 도커 소켓
(/var/run/docker.sock)에 의존하고 있는 경우, 다른
(`/var/run/docker.sock`)에 의존하고 있는 경우, 다른
런타임으로 전환하는 것은 해당 워크플로의 사용에 문제를 일으킵니다. 이 패턴은 종종
도커 내의 도커라고 합니다. 이런 특정 유스케이스에 대해서
[kaniko](https://github.com/GoogleContainerTools/kaniko),
@ -82,11 +82,11 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
이 변경 사항은 사람들(folks)이 보통 도커와 상호 작용하는 데 사용하는 것과는 다른 환경을
제시합니다. 개발에 사용하는 도커의 설치는 쿠버네티스 클러스터 내의
도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다. 개발자에게
도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히
도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다.
개발자에게 도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히
유용합니다. 도커가 생성하는 이미지는 실제로는
도커에만 특정된 이미지가 아니라 OCI([Open Container Initiative](https://opencontainers.org/)) 이미지입니다.
모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이
모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이
쿠버네티스에서 동일하게 보입니다. [containerd](https://containerd.io/)와
[CRI-O](https://cri-o.io/)는 모두 해당 이미지를 가져와 실행하는 방법을 알고 있습니다. 이것이
컨테이너가 어떤 모습이어야 하는지에 대한 표준이 있는 이유입니다.
@ -98,7 +98,7 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
혼란스럽더라도 괜찮습니다. 이에 대해서 많은 일이 진행되고 있습니다. 쿠버네티스에는 변화되는
부분이 많이 있고, 이에 대해 100% 전문가는 없습니다. 경험 수준이나
복잡성에 관계없이 어떤 질문이든 하시기 바랍니다! 우리의 목표는
모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. `<3` 이 글이
여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다!
모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. 이 글이
여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다! ❤️
더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 사용 중단 FAQ](/blog/2020/12/02/dockershim-faq/)를 확인하세요.

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

@ -239,7 +239,7 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는
쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
하트비트의 두 가지 형태는 `NodeStatus` 와
[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다.
[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)이다.
각 노드에는 `kube-node-lease` 라는
{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다.
리스는 경량 리소스로, 클러스터가 확장될 때
@ -355,4 +355,3 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 읽어본다.
* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.

10
content/ko/docs/concepts/cluster-administration/certificates.md
View File

@ -34,7 +34,7 @@ weight: 20
이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와
컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인수로
지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인수는 인증서가 만료되는
일 수를 설정하는데 사용된다.
일 수를 설정하는데 사용된다.
또한, 아래 샘플은 기본 DNS 이름으로 `cluster.local` 을
사용한다고 가정한다.
@ -130,11 +130,11 @@ weight: 20
사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플
명령을 조정해야 할 수도 있다.
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
1. 아티팩트(artifact)를 보유할 디렉터리를 생성하고 cfssl을 초기화한다.
@ -248,5 +248,3 @@ done.
`certificates.k8s.io` API를 사용해서
[여기](/docs/tasks/tls/managing-tls-in-a-cluster)에
설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다.

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

@ -1,4 +1,6 @@
---
title: 구성 모범 사례
content_type: concept
weight: 10
@ -67,6 +69,8 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
- 일반적인 활용 사례인 경우 [쿠버네티스 공통 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)을 사용한다. 이 표준화된 레이블은 `kubectl` 및 [대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard)와 같은 도구들이 상호 운용이 가능한 방식으로 동작할 수 있도록 메타데이터를 향상시킨다.
- 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다.
## 컨테이너 이미지

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

@ -767,7 +767,7 @@ immutable: true
`imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
`imagePullSecretsDocker` 를 사용하여 도커(또는 다른 컨테이너) 이미지 레지스트리
비밀번호가 포함된 시크릿을 kubelet에 전달할 수 있다. kubelet은 이 정보를 사용해서 파드를 대신하여 프라이빗 이미지를 가져온다.
`imagePullSecrets` 필드에 대한 자세한 정보는 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)를 참고한다.
`imagePullSecrets` 필드에 대한 자세한 정보는 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)를 참고한다.
#### imagePullSecret 수동으로 지정하기

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

@ -1,4 +1,7 @@
---
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
@ -34,10 +37,10 @@ weight: 20
런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
참고한다. `RuntimeClass` 기능 게이트는 API 서버 _및_ kubelets에서 활성화되어야 한다.
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
2. 상응하는 런타임클래스 리소스 생성
1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
2. 상응하는 런타임클래스 리소스 생성.
### 1. CRI 구현을 노드에 설정
@ -48,7 +51,7 @@ weight: 20
{{< note >}}
런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다.
이종의(heterogeneous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다.
{{< /note >}}
해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임클래스에 의해서 참조된다.
@ -95,7 +98,7 @@ spec:
# ...
```
이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
이것은 kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다.
에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를

3
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -1,4 +1,5 @@
---
title: 장치 플러그인
description: GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다.
content_type: concept
@ -199,7 +200,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
에이전트는 특권을 가진 ​​보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
데몬셋으로 실행 중인 경우, 플러그인의 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
데몬셋으로 실행 중인 경우, 해당 장치 모니터링 에이전트의 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
`/var/lib/kubelet/pod-resources` 를
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.

2
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
View File

@ -155,5 +155,5 @@ AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=900
## 용법 요약
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
* `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge` 및 `host-local` 플러그인과 함께 kubenet 네트워크 플러그인을 사용하도록 지정한다.
* `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge`, `lo` 및 `host-local` 플러그인과 함께 `kubenet` 네트워크 플러그인을 사용하도록 지정한다.
* 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다.

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

@ -1,4 +1,8 @@
---
title: 노드에 파드 할당하기
content_type: concept
weight: 50
@ -62,7 +66,7 @@ spec:
{{< codenew file="pods/pod-nginx.yaml" >}}
그런 다음에 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 을
실행하면, 레이블이 붙여진 노드에 파드가 스케줄 된다.
실행하면, 레이블이 붙여진 노드에 파드가 스케줄된다.
`kubectl get pods -o wide` 를 실행해서 파드가 할당된
"NODE" 를 보면 작동하는지 검증할 수 있다.
@ -100,7 +104,7 @@ spec:
1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된
정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다.
2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도,
파드가 계속 스케줄 되도록 한다.
파드가 계속 스케줄되도록 한다.
3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다.
이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다.
@ -115,7 +119,7 @@ spec:
스케줄할 수 있는 노드를 제한할 수 있다.
여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄 되도록 *반드시*
두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시*
규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고,
후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서
이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다.
@ -143,14 +147,14 @@ spec:
`NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나,
특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다.
`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는
`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄되기 위해서는
*둘 다* 반드시 만족해야 한다.
`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, 파드는 `nodeSelectorTerms` 를 **모두** 만족하는 노드에만 스케줄할 수 있다.
`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, `nodeSelectorTerms` 중 **하나라도** 만족시키는 노드에 파드가 스케줄된다.
`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 이 지정된 것 중 **한 가지**라도 만족하는 노드에만 스케줄할 수 있다.
`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄된다.
파드가 스케줄 된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
파드가 스케줄된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다.
`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.
@ -158,9 +162,9 @@ spec:
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때
여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때
노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다.
이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는
이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는
[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 인수에 `addedAffinity`를 추가한다. 예를 들면
```yaml
@ -183,15 +187,15 @@ profiles:
- foo
```
`addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며
`addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며
PodSpec에 지정된 NodeAffinity도 적용된다.
즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다.
`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의
`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의
스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다.
{{< note >}}
[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는
[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는
스케줄링 프로파일을 인식하지 못한다.
따라서 `addedAffinity`없이 `default-scheduler`와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다.
그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다.
@ -429,5 +433,3 @@ spec:
파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
노드 수준의 리소스 할당 결정에 참여할 수 있다.

4
content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
View File

@ -26,7 +26,7 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
이 수행될 때 지정된다.
파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나
파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
## 파드 오버헤드 활성화하기 {#set-up}
@ -190,4 +190,4 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)
* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)

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

@ -1,4 +1,8 @@
---
title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
content_type: concept
weight: 50
@ -8,8 +12,9 @@ weight: 50
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서
확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
kube-scheduler는 `RequestedToCapacityRatioResourceAllocation`
우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록
구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
kube-scheduler를 미세 조정할 수 있다.
<!-- body -->

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

@ -17,7 +17,6 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
[nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.
<!-- body -->
## 추가 컨트롤러
@ -27,6 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
컨트롤러다.
* [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
@ -73,4 +73,3 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).

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

@ -1,4 +1,8 @@
---
title: 네트워크 정책
content_type: concept
weight: 50
@ -31,6 +35,8 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
두 파드간 네트워크 흐름을 허용하기 위해서는, 소스 파드의 이그레스 정책과 목적지 파드의 인그레스 정책 모두가 해당 트래픽을 허용해야 한다. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하게 되어 있다면, 해당 트래픽은 거절될 것이다.
## 네트워크폴리시 리소스 {#networkpolicy-resource}
리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.

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

@ -1,4 +1,6 @@
---
title: 서비스
feature:
title: 서비스 디스커버리와 로드 밸런싱
@ -204,10 +206,10 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
`appProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는
`mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.
@ -236,7 +238,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
이 모드에서는, kube-proxy는 쿠버네티스 마스터의 서비스, 엔드포인트 오브젝트의
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
@ -602,8 +604,8 @@ status:
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
@ -618,7 +620,7 @@ kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
v1.20부터는 `spec.allocateLoadBalancerNodePorts`필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
@ -1210,8 +1212,8 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다.
type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다.
type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
클라우드 공급자에 따라 다르다. (대부분 그렇지 않음)
#### 경고 {#caveat-sctp-overview}

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

@ -1,4 +1,10 @@
---
title: 퍼시스턴트 볼륨
feature:
title: 스토리지 오케스트레이션
@ -225,7 +231,7 @@ spec:
* Azure Disk
* Portworx
* FlexVolumes
* CSI
* {{< glossary_tooltip text="CSI" term_id="csi" >}}
스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다.
@ -317,14 +323,14 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
(단일 노드 테스트 전용. 다중-노드 클러스터에서 작동하지 않음.
(단일 노드 테스트 전용. 다중-노드 클러스터에서 작동하지 않음.
대신 `로컬` 볼륨 사용 고려)
* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 스토리지
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
로컬 스토리지 디바이스
* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
(이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
(이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
작동하지 않는다.)
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨

9
content/ko/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -1,4 +1,11 @@
---
title: 볼륨 스냅샷 클래스
content_type: concept
weight: 30
@ -65,7 +72,7 @@ parameters:
### 삭제정책(DeletionPolicy)
볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅삿의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다.
볼륨 스냅샷 클래스는 삭제정책을 가지고 있다. 바인딩된 볼륨스냅샷 오브젝트를 삭제할 때 VolumeSnapshotContent의 상황을 구성할 수 있다. 볼륨 스냅샷 클래스의 삭제정책은 `Retain` 또는 `Delete` 일 수 있다. 이 필드는 반드시 지정해야 한다.
삭제정책이 `Delete` 인 경우 기본 스토리지 스냅샷이 VolumeSnapshotContent 오브젝트와 함께 삭제된다. 삭제정책이 `Retain` 인 경우 기본 스냅샷과 VolumeSnapshotContent 모두 유지된다.

9
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
View File

@ -150,9 +150,12 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
```
kubectl도 캐스케이딩 삭제를 지원한다.
kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을
분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은
true 이다.
kubectl을 사용해서 포어그라운드의 종속 항목을 삭제하려면 `--cascade=foreground` 를 설정한다. 종속 항목을
분리하기 위해서는 `--cascade=orphan` 를 설정한다.
기본 동작은 백그라운드의 종속 항목을 삭제하는 것이며,
이는 `--cascade` 를 생략하거나 명시적으로 `background` 를 설정한 경우의 동작에 해당한다.
여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.

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

@ -1,4 +1,8 @@
---
title: 레플리카셋
content_type: concept
weight: 20
@ -279,7 +283,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
### 레플리카셋만 삭제하기
레플리카셋을 `--cascade=false` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
레플리카셋을 `--cascade=orphan` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다.
예시:
```shell

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

@ -1,4 +1,7 @@
---
title: 레플리케이션 컨트롤러
feature:
title: 자가 치유
@ -51,15 +54,17 @@ kubectl 명령에서 숏컷으로 사용된다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
```
출력 결과는 다음과 같다.
```
replicationcontroller/nginx created
```
다음 명령을 사용하여 레플리케이션 컨트롤러의 상태를 확인하라.
다음 명령을 사용하여 레플리케이션 컨트롤러의 상태를 확인하자.
```shell
kubectl describe replicationcontrollers/nginx
```
출력 결과는 다음과 같다.
```
Name: nginx
Namespace: default
@ -98,6 +103,7 @@ Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods
```
출력 결과는 다음과 같다.
```
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```

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

@ -15,8 +15,7 @@ card:
_파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
_파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
[컨테이너](/ko/docs/concepts/containers/)의 그룹이다.
이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
[컨테이너](/ko/docs/concepts/containers/)의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
애플리케이션 컨테이너가 포함된다.
@ -217,7 +216,8 @@ spec:
허용한다.
1. 지정되지 않은 필드를 양수로 설정;
1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
1. 필드의 양수를 음수가 아닌 더 작은 숫자로
갱신.
## 리소스 공유와 통신
@ -294,9 +294,10 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
오브젝트 정의는 오브젝트를 상세히 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음을 포함한 선행 기술에 대해 읽어볼 수 있다.
* [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
* [Borg](https://research.google.com/pubs/pub43438.html)
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
* [Omega](https://research.google/pubs/pub41684/)
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
* [Borg](https://research.google.com/pubs/pub43438.html)
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
* [Omega](https://research.google/pubs/pub41684/)
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).

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

@ -1,4 +1,8 @@
---
title: 중단(disruption)
content_type: concept
weight: 60
@ -45,7 +49,7 @@ weight: 60
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
- 클러스터의 스케일 축소를 위한
노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기
노드 드레이닝([클러스터 오토스케일링](https://github.com/kubernetes/autoscaler/#readme)에 대해 알아보기
).
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.

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

@ -133,6 +133,7 @@ spec:
```shell
kubectl apply -f myapp.yaml
```
출력 결과는 다음과 같다.
```
pod/myapp-pod created
```
@ -141,6 +142,7 @@ pod/myapp-pod created
```shell
kubectl get -f myapp.yaml
```
출력 결과는 다음과 같다.
```
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
@ -150,6 +152,7 @@ myapp-pod 0/1 Init:0/2 0 6m
```shell
kubectl describe -f myapp.yaml
```
출력 결과는 다음과 같다.
```
Name: myapp-pod
Namespace: default
@ -224,6 +227,7 @@ spec:
```shell
kubectl apply -f services.yaml
```
출력 결과는 다음과 같다.
```
service/myservice created
service/mydb created
@ -235,6 +239,7 @@ service/mydb created
```shell
kubectl get -f myapp.yaml
```
출력 결과는 다음과 같다.
```
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
@ -257,7 +262,7 @@ myapp-pod 1/1 Running 0 9m
파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
`Initialized` 가 참이 되는 조건을 가져야 한다.
`Initialized` 가 거짓이 되는 조건을 가져야 한다.
만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
반드시 다시 실행된다.

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

@ -85,6 +85,13 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.
{{< note >}}
파드가 삭제될 때, 일부 kubectl 커맨드에서 `Terminating` 이 표시된다.
이 `Terminating` 상태는 파드의 단계에 해당하지 않는다.
파드에는 그레이스풀하게(gracefully) 종료되도록 기간이 부여되며, 그 기본값은 30초이다.
[강제로 파드를 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)하려면 `--force` 플래그를 설정하면 된다.
{{< /note >}}
노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는
손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다.
@ -142,8 +149,7 @@ Never이다. 기본값은 Always이다.
동일한 노드에서 kubelet에 의한 컨테이너 재시작만을 의미한다. 파드의 컨테이너가
종료된 후, kubelet은 5분으로 제한되는 지수 백오프 지연(10초, 20초, 40초, …)으로
컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면,
kubelet은 해당 컨테이너의 재시작 백오프 타이머를
재설정한다.
kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한다.
## 파드의 조건
@ -326,7 +332,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds`
이후에 기동된다면, 스타트업 프로브가
활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다.
`periodSeconds`의 기본값은 30s 이다. 이 때 컨테이너가 활성화 프로브의
`periodSeconds`의 기본값은 10s 이다. 이 때 컨테이너가 활성화 프로브의
기본값 변경 없이 기동되도록 하려면, `failureThreshold` 를 충분히 높게 설정해주어야
한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.

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

@ -166,7 +166,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `Sysctls` | `true` | 베타 | 1.11 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | |
| `TopologyManager` | `false` | 알파 | 1.16 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |

5
content/ko/docs/reference/kubectl/cheatsheet.md
View File

@ -190,6 +190,9 @@ kubectl get pods --show-labels
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# 외부 도구 없이 디코딩된 시크릿 출력
kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}'
# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
@ -311,6 +314,7 @@ kubectl exec my-pod -- ls / # 기존 파드에서 명령
kubectl exec --stdin --tty my-pod -- /bin/sh # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
```
## 노드, 클러스터와 상호 작용
@ -388,6 +392,7 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
`--v=2` | 서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다.
`--v=3` | 변경 사항에 대한 확장 정보.
`--v=4` | 디버그 수준 상세화.
`--v=5` | 트레이스 수준 상세화.
`--v=6` | 요청한 리소스를 표시.
`--v=7` | HTTP 요청 헤더를 표시.
`--v=8` | HTTP 요청 내용을 표시.

39
content/ko/docs/reference/kubectl/conventions.md
View File

@ -1,7 +1,7 @@
---
title: kubectl 사용 규칙
content_type: concept
---
@ -36,24 +36,23 @@ content_type: concept
{{< /note >}}
#### 생성기
`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성 할 수 있다.
```
clusterrole 클러스터롤(ClusterRole)를 생성한다.
clusterrolebinding 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
configmap 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
cronjob 지정된 이름으로 크론잡(CronJob)을 생성한다.
deployment 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
job 지정된 이름으로 잡(Job)을 생성한다.
namespace 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
poddisruptionbudget 지정된 이름으로 pod disruption budget을 생성한다.
priorityclass 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
quota 지정된 이름으로 쿼터(Quota)를 생성한다.
role 단일 규칙으로 롤(Role)을 생성한다.
rolebinding 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
secret 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
service 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
serviceaccount 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
```
`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.
* `clusterrole`: 클러스터롤(ClusterRole)를 생성한다.
* `clusterrolebinding`: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
* `configmap`: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
* `cronjob`: 지정된 이름으로 크론잡(CronJob)을 생성한다.
* `deployment`: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
* `job`: 지정된 이름으로 잡(Job)을 생성한다.
* `namespace`: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
* `poddisruptionbudget`: 지정된 이름으로 PodDisruptionBudget을 생성한다.
* `priorityclass`: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
* `quota`: 지정된 이름으로 쿼터(Quota)를 생성한다.
* `role`: 단일 규칙으로 롤(Role)을 생성한다.
* `rolebinding`: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
* `secret`: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
* `service`: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
* `serviceaccount`: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
### `kubectl apply`

8
content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
View File

@ -37,16 +37,11 @@ kubectl:
# nginx 실행하는 파드를 시작한다
kubectl create deployment --image=nginx nginx-app
```
```shell
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
```
```
deployment.apps/nginx-app created
```
```
```shell
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
```
@ -369,4 +364,3 @@ Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/servic
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
```

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

@ -143,6 +143,44 @@ sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
```
{{% /tab %}}
{{% tab name="Debian 9+" %}}
```shell
# (containerd 설치)
## 리포지터리 설정
### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
```shell
## 도커의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
```
```shell
## 도커 apt 리포지터리 추가
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"
```
```shell
## containerd 설치
sudo apt-get update && sudo apt-get install -y containerd.io
```
```shell
# 기본 containerd 구성 설정
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
```
```shell
# containerd 재시작
sudo systemctl restart containerd
@ -230,12 +268,18 @@ kubeadm을 사용하는 경우,
{{< note >}}
CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다.
더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다.
더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)를 본다.
{{< /note >}}
필수 구성 요소를 설치하고 구성한다.
```shell
# .conf 파일을 만들어 부팅 시 모듈을 로드한다
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
@ -262,9 +306,9 @@ sudo sysctl --system
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
@ -298,9 +342,9 @@ sudo apt-get install cri-o cri-o-runc
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
@ -332,9 +376,9 @@ apt-get install cri-o cri-o-runc
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.18.3을 설치하려면, `VERSION=1.18:1.18.3` 을 설정한다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
@ -355,7 +399,7 @@ sudo zypper install cri-o
{{% tab name="Fedora" %}}
`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.18을 설치하려면, `VERSION=1.18` 로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용할 수 있는 버전을 찾으려면 다음을 실행한다.
```shell
@ -379,10 +423,26 @@ sudo systemctl daemon-reload
sudo systemctl start crio
```
자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를
자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를
참고한다.
#### cgroup 드라이버
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. `cgroupfs` cgroup 드라이버로
전환하려면, `/etc/crio/crio.conf` 를 수정하거나 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에
드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다.
```toml
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
```
또한 `cgroupfs` 와 함께 CRI-O를 사용할 때 `pod` 값으로 설정해야 하는
변경된 `conmon_cgroup` 에 유의한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과
CRI-O의 cgroup 드라이버 구성을 동기화 상태로
유지해야 한다.
### 도커
@ -425,6 +485,11 @@ sudo apt-get update && sudo apt-get install -y \
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
```
```shell
## /etc/docker 생성
sudo mkdir /etc/docker
```
```shell
# 도커 데몬 설정
cat <<EOF | sudo tee /etc/docker/daemon.json

85
content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md
View File

@ -6,17 +6,19 @@ weight: 70
<!-- overview -->
이 작업은 프론트엔드와 마이크로서비스 백엔드를 어떻게 생성하는지를
설명한다. 백엔드 마이크로서비스는 인사하기(hello greeter)이다.
프론트엔드와 백엔드는 쿠버네티스 {{< glossary_tooltip term_id="service" text="서비스" >}}
오브젝트를 이용해 연결되어 있다.
이 작업은 _프론트엔드_ 와 _백엔드_ 마이크로서비스를 어떻게 생성하는지를 설명한다. 백엔드
마이크로서비스는 인사하기(hello greeter)이다. 프론트엔드는 nginx 및 쿠버네티스
{{< glossary_tooltip term_id="service" text="서비스" >}} 오브젝트를 사용해 백엔드를 노출한다.
## {{% heading "objectives" %}}
* {{< glossary_tooltip term_id="deployment" text="디플로이먼트(Deployment)" >}} 오브젝트를 사용해 마이크로서비스를 생성하고 실행한다.
* 프론트엔드를 사용하여 백엔드로 트래픽을 전달한다.
* 프론트엔드 애플리케이션을 백엔드 애플리케이션에 연결하기 위해
서비스 오브젝트를 사용한다.
* {{< glossary_tooltip term_id="deployment" text="디플로이먼트(Deployment)" >}} 오브젝트를 사용해
샘플 `hello` 백엔드 마이크로서비스를 생성하고 실행한다.
* 서비스 오브젝트를 사용하여 백엔드 마이크로서비스의 여러 복제본으로 트래픽을 보낸다.
* 디플로이먼트 오브젝트를 사용하여 `nginx` 프론트엔드 마이크로서비스를 생성하고 실행한다.
* 트래픽을 백엔드 마이크로서비스로 보내도록 프론트엔드 마이크로서비스를 구성한다.
* `type=LoadBalancer` 의 서비스 오브젝트를 사용해 클러스터 외부에 프론트엔드 마이크로서비스를
노출한다.
## {{% heading "prerequisites" %}}
@ -34,24 +36,24 @@ weight: 70
백엔드는 인사하기라는 간단한 마이크로서비스이다. 여기에 백엔드 디플로이먼트
구성 파일이 있다.
{{< codenew file="service/access/hello.yaml" >}}
{{< codenew file="service/access/backend-deployment.yaml" >}}
백엔드 디플로이먼트를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml
```
백엔드 디플로이먼트에 관한 정보를 본다.
```shell
kubectl describe deployment hello
kubectl describe deployment backend
```
결과는 아래와 같다.
```
Name: hello
Name: backend
Namespace: default
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
Labels: app=hello
@ -59,7 +61,7 @@ Labels: app=hello
track=stable
Annotations: deployment.kubernetes.io/revision=1
Selector: app=hello,tier=backend,track=stable
Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
@ -80,14 +82,14 @@ Conditions:
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: hello-3621623197 (7/7 replicas created)
NewReplicaSet: hello-3621623197 (3/3 replicas created)
Events:
...
```
## 백엔드 서비스 오브젝트 생성하기
## `hello` 서비스 오브젝트 생성하기
프론트엔드와 백엔드를 연결하는 방법은 백엔드
프론트엔드에서 백엔드로 요청을 보내는 핵심은 백엔드
서비스이다. 서비스는 백엔드 마이크로서비스에 언제든 도달하기 위해
변하지 않는 IP 주소와 DNS 이름 항목을 생성한다. 서비스는
트래픽을 보내는 파드를 찾기 위해
@ -95,42 +97,51 @@ Events:
먼저, 서비스 구성 파일을 살펴보자.
{{< codenew file="service/access/hello-service.yaml" >}}
{{< codenew file="service/access/backend-service.yaml" >}}
구성 파일에서 서비스가 `app: hello` 과 `tier: backend` 레이블을 갖는
구성 파일에서 `hello` 라는 이름의 서비스가 `app: hello` 및 `tier: backend` 레이블을 갖는
파드에 트래픽을 보내는 것을 볼 수 있다.
`hello` 서비스를 생성한다.
백엔드 서비스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml
```
이 시점에서, 백엔드 디플로이먼트는 Running 중이며, 해당 백엔드로
트래픽을 보내는 서비스를 갖고 있다.
이 시점에서 `hello` 애플리케이션의 복제본 3개를 실행하는 `backend`
디플로이먼트가 있고, 해당 백엔드로 트래픽을 보내는 서비스가 있다. 그러나, 이
서비스는 클러스터 외부에서 사용할 수 없거나 확인할 수 없다.
## 프론트엔드 생성하기
이제 백엔드가 있기 때문에 백엔드와 연결하는 프론트엔드를 생성할 수 있다.
프론트엔드는 백엔드 서비스에서 제공된 DNS 이름을 사용해 백엔드 워커
파드에 연결할 수 있다. DNS 이름은 "hello" 이고, 앞선
서비스 구성 파일의 `name` 항목의 값이다.
이제 백엔드를 실행했으므로, 클러스터 외부에서 접근할 수 있는
프론트엔드를 만들고, 백엔드로의 요청을 프록시하여 백엔드에 연결할 수 있다.
프론트엔드 디플로이먼트 안에 파드는 hello 백엔드 서비스를 찾도록
구성된 nginx 이미지를 실행한다. 여기에 nginx 구성 파일이 있다.
프론트엔드는 백엔드 서비스에 지정된 DNS 이름을 사용하여 백엔드
워커 파드에 요청을 보낸다. DNS 이름은
`examples/service/access/backend-service.yaml` 구성 파일의
`name` 필드 값인 `hello` 이다.
{{< codenew file="service/access/frontend.conf" >}}
프론트엔드 디플로이먼트 안의 파드는 `hello` 백엔드 서비스에 대한 요청을
프록시하도록 구성된 nginx 이미지를 실행한다. 다음은 nginx 구성 파일이다.
백엔드와 같이, 프론트엔드는 디플로이먼트와 서비스를 갖고 있다.
서비스의 구성은 `type: LoadBalancer` 이며, 이는 서비스가
클라우드 공급자의 기본 로드 밸런서를 사용하는 것을 의미한다.
{{< codenew file="service/access/frontend-nginx.conf" >}}
{{< codenew file="service/access/frontend.yaml" >}}
백엔드와 같이, 프론트엔드는 디플로이먼트와 서비스를 갖고 있다. 백엔드
서비스와 프론트엔드 서비스 간에 주목해야 할 중요한 차이점은 프론트엔드
서비스의 구성에 `type: LoadBalancer` 가 있다는 것이다. 즉,
서비스가 클라우드 공급자가 프로비저닝한 로드 밸런서를 사용하고
클러스터 외부에서 접근할 수 있음을 의미한다.
{{< codenew file="service/access/frontend-service.yaml" >}}
{{< codenew file="service/access/frontend-deployment.yaml" >}}
프론트엔드 디플로이먼트와 서비스를 생성한다.
```shell
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml
```
결과는 두 리소스가 생성되었음을 확인한다.
@ -196,17 +207,17 @@ curl http://${EXTERNAL_IP} # 앞의 예에서 본 EXTERNAL-IP로 수정한다
서비스를 삭제하기 위해, 아래 명령어를 입력하자.
```shell
kubectl delete services frontend hello
kubectl delete services frontend backend
```
백엔드와 프론트엔드 애플리케이션에서 실행 중인 디플로이먼트, 레플리카셋, 파드를 삭제하기 위해, 아래 명령어를 입력하자.
```shell
kubectl delete deployment frontend hello
kubectl delete deployment frontend backend
```
## {{% heading "whatsnext" %}}
* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 알아본다.
* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)에 대해 더 알아본다.
* [서비스와 파드용 DNS](/docs/concepts/services-networking/dns-pod-service/)에 대해 더 알아본다.

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

@ -392,8 +392,8 @@ spec:
containers:
- name: my-nginx
resources:
limits:
memory: 512Mi
limits:
memory: 512Mi
EOF
cat <<EOF >./kustomization.yaml
@ -424,11 +424,12 @@ spec:
spec:
containers:
- image: nginx
limits:
memory: 512Mi
name: my-nginx
ports:
- containerPort: 80
resources:
limits:
memory: 512Mi
```
모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해,

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

@ -103,9 +103,7 @@ weight: 10
<div class="row">
<div class="col-md-8">
<p>
첫 번째 디플로이먼트로, 도커 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자.
(Node.js 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면,
<a href="/ko/docs/tutorials/hello-minikube/">Hello Minikube 튜토리얼</a>의 지시를 따른다.)</p>
첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, <a href="/docs/tutorials/hello-minikube/">Hello Minikube 튜토리얼</a>의 지시를 따른다.)
<p>
<p>이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!</p>

2
content/ko/examples/application/deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment

2
content/ko/examples/application/guestbook/frontend-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend

2
content/ko/examples/application/guestbook/redis-master-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-master

2
content/ko/examples/application/guestbook/redis-slave-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-slave

2
content/ko/examples/application/mysql/mysql-deployment.yaml
View File

@ -9,7 +9,7 @@ spec:
app: mysql
clusterIP: None
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql

2
content/ko/examples/application/wordpress/mysql-deployment.yaml
View File

@ -25,7 +25,7 @@ spec:
requests:
storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress-mysql

2
content/ko/examples/application/wordpress/wordpress-deployment.yaml
View File

@ -25,7 +25,7 @@ spec:
requests:
storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress

2
content/ko/examples/service/access/Dockerfile
View File

@ -1,4 +1,4 @@
FROM nginx:1.17.3
RUN rm /etc/nginx/conf.d/default.conf
COPY frontend.conf /etc/nginx/conf.d
COPY frontend-nginx.conf /etc/nginx/conf.d

0
content/ko/examples/service/access/hello.yaml → content/ko/examples/service/access/backend-deployment.yaml
View File

0
content/ko/examples/service/access/hello-service.yaml → content/ko/examples/service/access/backend-service.yaml
View File

27
content/ko/examples/service/access/frontend-deployment.yaml Normal file
View File

@ -0,0 +1,27 @@
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
lifecycle:
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]
...

14
content/ko/examples/service/access/frontend-nginx.conf Normal file
View File

@ -0,0 +1,14 @@
# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
# hello is the internal DNS name used by the backend Service inside Kubernetes
server hello;
}
server {
listen 80;
location / {
# The following statement will proxy traffic to the upstream named Backend
proxy_pass http://Backend;
}
}

15
content/ko/examples/service/access/frontend-service.yaml Normal file
View File

@ -0,0 +1,15 @@
---
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
...

11
content/ko/examples/service/access/frontend.conf
View File

@ -1,11 +0,0 @@
upstream hello {
server hello;
}
server {
listen 80;
location / {
proxy_pass http://hello;
}
}

39
content/ko/examples/service/access/frontend.yaml
View File

@ -1,39 +0,0 @@
apiVersion: v1
kind: Service
metadata:
name: frontend
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
lifecycle:
preStop:
exec:
command: ["/usr/sbin/nginx","-s","quit"]