diff --git a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index de7d44ecad..b7550a3d83 100644 --- a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -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/)를 확인하세요. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 18133b6577..6872096814 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -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/)을 읽어본다. - diff --git a/content/ko/docs/concepts/cluster-administration/certificates.md b/content/ko/docs/concepts/cluster-administration/certificates.md index d7051e4145..7b71b9c344 100644 --- a/content/ko/docs/concepts/cluster-administration/certificates.md +++ b/content/ko/docs/concepts/cluster-administration/certificates.md @@ -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 인증서를 프로비전 할 수 있다. - - diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 5e2047b367..6bcec1d6c0 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -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)를 사용할 수 있다. ## 컨테이너 이미지 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index f120b0002d..e5466b8dec 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -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 수동으로 지정하기 diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 674f47b32a..b31cabe888 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -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/)를 diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 56230e5911..5f58604cd7 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -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" >}}으로 마운트해야 한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 76c2bdd003..7542ac0add 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -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를 지정한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index edbe7daf39..ebbc00f91e 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -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/)는 노드 수준의 리소스 할당 결정에 참여할 수 있다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index 29ab845af2..0f474338d9 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -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) diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 124f009020..f23396d936 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -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를 미세 조정할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 7690669757..3af939488e 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -17,7 +17,6 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다. - ## 추가 컨트롤러 @@ -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). - diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index be145f78c9..d7872b1d92 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -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) 를 본다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 3270c498aa..da9d353d6f 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -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} diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 2b421c7fb2..9ce1eba6cf 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -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 볼륨 diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 11708eeec5..e5b6002e6e 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -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 모두 유지된다. diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index a93b455948..a3ed4ea68d 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -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` 를 설정한 경우의 동작에 해당한다. 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index c5a6832fd9..8966029620 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -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 diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 5c5b5c750f..9c3450851a 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -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 ``` diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 265f971816..8645053bef 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -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/). diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 5f13dddef9..02647adb70 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -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)에 대해 알아보기 ). - 노드에 다른 무언가를 추가하기 위해 파드를 제거. diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index c1e3943178..56f59c1d30 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -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` 가 거짓이 되는 조건을 가져야 한다. 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 반드시 다시 실행된다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 0c4ea5960c..1066e3eb83 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -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)을 방지하는데 도움이 된다. diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index ad9c9a45de..6fa2c58a56 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -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 | | diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 7db5ce3bdb..2ac5f6076c 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -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 요청 내용을 표시. diff --git a/content/ko/docs/reference/kubectl/conventions.md b/content/ko/docs/reference/kubectl/conventions.md index b18f64b5ef..aa76c0c8bf 100644 --- a/content/ko/docs/reference/kubectl/conventions.md +++ b/content/ko/docs/reference/kubectl/conventions.md @@ -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` diff --git a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md index e81dd65b4a..1679059871 100644 --- a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -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 ``` - diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 8bdd90800b..4b749ab7e5 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -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 < 그런 다음, `$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` 을 설정한다.
그런 다음, 아래를 실행한다. @@ -298,9 +342,9 @@ sudo apt-get install cri-o cri-o-runc
그런 다음, `$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` 을 설정한다.
그런 다음, 아래를 실행한다. @@ -332,9 +376,9 @@ apt-get install cri-o cri-o-runc
그런 다음, `$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` 을 설정한다.
그런 다음, 아래를 실행한다. @@ -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 < -이 작업은 프론트엔드와 마이크로서비스 백엔드를 어떻게 생성하는지를 -설명한다. 백엔드 마이크로서비스는 인사하기(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: -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/)에 대해 더 알아본다. diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index fd59ccfd4f..c9ed347c56 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -392,8 +392,8 @@ spec: containers: - name: my-nginx resources: - limits: - memory: 512Mi + limits: + memory: 512Mi EOF cat <./kustomization.yaml @@ -424,11 +424,12 @@ spec: spec: containers: - image: nginx - limits: - memory: 512Mi name: my-nginx ports: - containerPort: 80 + resources: + limits: + memory: 512Mi ``` 모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 6cf468f0b6..5b41fe207a 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -103,9 +103,7 @@ weight: 10

- 첫 번째 디플로이먼트로, 도커 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자. - (Node.js 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, - Hello Minikube 튜토리얼의 지시를 따른다.)

+ 첫 번째 디플로이먼트로, NGINX를 사용해 모든 요청을 에코(echo)하는 도커 컨테이너로 패키지한 hello-node 애플리케이션을 사용해보자. (아직 hello-node 애플리케이션을 작성하고 컨테이너를 활용해서 배포해보지 않았다면, Hello Minikube 튜토리얼의 지시를 따른다.)

이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!

diff --git a/content/ko/examples/application/deployment.yaml b/content/ko/examples/application/deployment.yaml index 2cd599218d..dbed8bc72b 100644 --- a/content/ko/examples/application/deployment.yaml +++ b/content/ko/examples/application/deployment.yaml @@ -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 diff --git a/content/ko/examples/application/guestbook/frontend-deployment.yaml b/content/ko/examples/application/guestbook/frontend-deployment.yaml index 50d6e1f0d4..23d64be644 100644 --- a/content/ko/examples/application/guestbook/frontend-deployment.yaml +++ b/content/ko/examples/application/guestbook/frontend-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: frontend diff --git a/content/ko/examples/application/guestbook/redis-master-deployment.yaml b/content/ko/examples/application/guestbook/redis-master-deployment.yaml index fc6f418c39..478216d1ac 100644 --- a/content/ko/examples/application/guestbook/redis-master-deployment.yaml +++ b/content/ko/examples/application/guestbook/redis-master-deployment.yaml @@ -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 diff --git a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml index 7dcfb6c263..1a7b04386a 100644 --- a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml +++ b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml @@ -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 diff --git a/content/ko/examples/application/mysql/mysql-deployment.yaml b/content/ko/examples/application/mysql/mysql-deployment.yaml index 518457777e..419fbe03d3 100644 --- a/content/ko/examples/application/mysql/mysql-deployment.yaml +++ b/content/ko/examples/application/mysql/mysql-deployment.yaml @@ -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 diff --git a/content/ko/examples/application/wordpress/mysql-deployment.yaml b/content/ko/examples/application/wordpress/mysql-deployment.yaml index 8b92b76f54..c6b221512d 100644 --- a/content/ko/examples/application/wordpress/mysql-deployment.yaml +++ b/content/ko/examples/application/wordpress/mysql-deployment.yaml @@ -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 diff --git a/content/ko/examples/application/wordpress/wordpress-deployment.yaml b/content/ko/examples/application/wordpress/wordpress-deployment.yaml index d898474211..c8ed239142 100644 --- a/content/ko/examples/application/wordpress/wordpress-deployment.yaml +++ b/content/ko/examples/application/wordpress/wordpress-deployment.yaml @@ -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 diff --git a/content/ko/examples/service/access/Dockerfile b/content/ko/examples/service/access/Dockerfile index b7b09d492a..61c8ce2831 100644 --- a/content/ko/examples/service/access/Dockerfile +++ b/content/ko/examples/service/access/Dockerfile @@ -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 diff --git a/content/ko/examples/service/access/hello.yaml b/content/ko/examples/service/access/backend-deployment.yaml similarity index 100% rename from content/ko/examples/service/access/hello.yaml rename to content/ko/examples/service/access/backend-deployment.yaml diff --git a/content/ko/examples/service/access/hello-service.yaml b/content/ko/examples/service/access/backend-service.yaml similarity index 100% rename from content/ko/examples/service/access/hello-service.yaml rename to content/ko/examples/service/access/backend-service.yaml diff --git a/content/ko/examples/service/access/frontend-deployment.yaml b/content/ko/examples/service/access/frontend-deployment.yaml new file mode 100644 index 0000000000..182b0e708e --- /dev/null +++ b/content/ko/examples/service/access/frontend-deployment.yaml @@ -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"] +... \ No newline at end of file diff --git a/content/ko/examples/service/access/frontend-nginx.conf b/content/ko/examples/service/access/frontend-nginx.conf new file mode 100644 index 0000000000..39a911a09a --- /dev/null +++ b/content/ko/examples/service/access/frontend-nginx.conf @@ -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; + } +} diff --git a/content/ko/examples/service/access/frontend-service.yaml b/content/ko/examples/service/access/frontend-service.yaml new file mode 100644 index 0000000000..898a5ed51b --- /dev/null +++ b/content/ko/examples/service/access/frontend-service.yaml @@ -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 +... \ No newline at end of file diff --git a/content/ko/examples/service/access/frontend.conf b/content/ko/examples/service/access/frontend.conf deleted file mode 100644 index 9a1f5a0ed6..0000000000 --- a/content/ko/examples/service/access/frontend.conf +++ /dev/null @@ -1,11 +0,0 @@ -upstream hello { - server hello; -} - -server { - listen 80; - - location / { - proxy_pass http://hello; - } -} diff --git a/content/ko/examples/service/access/frontend.yaml b/content/ko/examples/service/access/frontend.yaml deleted file mode 100644 index 9f5b6b757f..0000000000 --- a/content/ko/examples/service/access/frontend.yaml +++ /dev/null @@ -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"]