From 6166f998926a261aae3b867e4c4d75f5df0f912b Mon Sep 17 00:00:00 2001 From: Jerry Park Date: Fri, 7 Aug 2020 06:25:21 +0000 Subject: [PATCH] Tenth Korean l10n work for release 1.18 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Translate concepts/extend-kubenetes/service-catalog.md in Korean (#23233) - Translate concepts/configuration/secret.md into Korean (#23110) - Translate tasks/extend-kubernetes/setup-extension-api-server.md into … (#22574) - Update outdated files in dev-1.18-ko.10 branch (#23013) Co-authored-by: Seokho Son Co-authored-by: Jerry Park Co-authored-by: santachopa --- .../control-plane-node-communication.md | 2 +- .../ko/docs/concepts/architecture/nodes.md | 4 +- .../concepts/cluster-administration/_index.md | 6 +- .../concepts/cluster-administration/addons.md | 11 +- .../cluster-administration/cloud-providers.md | 17 +- .../cluster-administration/logging.md | 7 +- .../manage-deployment.md | 8 +- .../cluster-administration/networking.md | 33 +- .../docs/concepts/configuration/configmap.md | 2 +- .../manage-resources-containers.md | 23 +- .../docs/concepts/configuration/overview.md | 2 +- .../configuration/pod-priority-preemption.md | 4 +- .../ko/docs/concepts/configuration/secret.md | 1268 +++++++++++++++++ .../containers/container-environment.md | 4 +- .../containers/container-lifecycle-hooks.md | 2 +- content/ko/docs/concepts/containers/images.md | 2 +- .../docs/concepts/extend-kubernetes/_index.md | 32 +- .../api-extension/apiserver-aggregation.md | 5 - .../api-extension/custom-resources.md | 6 +- .../compute-storage-net/device-plugins.md | 8 +- .../extend-kubernetes/extend-cluster.md | 45 +- .../concepts/extend-kubernetes/operator.md | 3 - .../extend-kubernetes/service-catalog.md | 236 +++ .../docs/concepts/overview/kubernetes-api.md | 13 +- .../kubernetes-objects.md | 2 +- .../overview/working-with-objects/labels.md | 19 +- .../working-with-objects/namespaces.md | 17 +- .../working-with-objects/object-management.md | 4 - .../ko/docs/concepts/policy/limit-range.md | 10 +- .../concepts/policy/pod-security-policy.md | 15 +- .../docs/concepts/policy/resource-quotas.md | 18 +- .../scheduling-eviction/kube-scheduler.md | 4 +- .../connect-applications-service.md | 2 +- .../services-networking/dns-pod-service.md | 15 +- .../ingress-controllers.md | 2 +- .../concepts/services-networking/ingress.md | 2 +- .../services-networking/network-policies.md | 2 - .../concepts/services-networking/service.md | 12 +- .../concepts/storage/persistent-volumes.md | 9 +- .../docs/concepts/storage/storage-classes.md | 2 - content/ko/docs/concepts/storage/volumes.md | 24 +- .../workloads/controllers/daemonset.md | 10 +- .../workloads/controllers/deployment.md | 22 +- .../controllers/garbage-collection.md | 6 - .../concepts/workloads/controllers/job.md | 7 +- .../controllers/replicationcontroller.md | 17 +- .../workloads/controllers/ttlafterfinished.md | 11 +- .../ko/docs/concepts/workloads/pods/_index.md | 267 +++- .../concepts/workloads/pods/disruptions.md | 55 +- .../concepts/workloads/pods/pod-lifecycle.md | 606 ++++---- .../concepts/workloads/pods/pod-overview.md | 120 -- .../pods/pod-topology-spread-constraints.md | 2 +- .../ko/docs/concepts/workloads/pods/pod.md | 206 --- .../docs/concepts/workloads/pods/podpreset.md | 41 +- content/ko/docs/contribute/_index.md | 4 +- .../ko/docs/contribute/participate/_index.md | 2 +- .../contribute/participate/pr-wranglers.md | 23 +- content/ko/docs/reference/glossary/pod.md | 7 +- .../docs/reference/using-api/api-overview.md | 12 +- .../setup/best-practices/cluster-large.md | 32 +- .../setup/best-practices/multiple-zones.md | 2 +- .../setup/learning-environment/minikube.md | 4 +- .../production-environment/tools/kops.md | 2 +- .../service-access-application-cluster.md | 8 +- .../change-pv-reclaim-policy.md | 20 +- .../kubeadm/adding-windows-nodes.md | 4 +- .../configure-pod-container/static-pod.md | 2 +- .../ko/docs/tasks/extend-kubernetes/_index.md | 5 + .../setup-extension-api-server.md | 53 + .../run-application/delete-stateful-set.md | 2 +- .../horizontal-pod-autoscale-walkthrough.md | 4 +- content/ko/docs/tasks/tools/_index.md | 35 + .../ko/docs/tasks/tools/install-kubectl.md | 2 +- content/ko/docs/tutorials/hello-minikube.md | 10 +- .../deploy-app/deploy-interactive.html | 2 +- .../expose/expose-intro.html | 2 +- .../ko/docs/tutorials/services/source-ip.md | 61 +- .../stateful-application/zookeeper.md | 87 +- .../expose-external-ip-address.md | 6 +- 79 files changed, 2570 insertions(+), 1093 deletions(-) create mode 100644 content/ko/docs/concepts/configuration/secret.md create mode 100644 content/ko/docs/concepts/extend-kubernetes/service-catalog.md delete mode 100644 content/ko/docs/concepts/workloads/pods/pod-overview.md delete mode 100644 content/ko/docs/concepts/workloads/pods/pod.md create mode 100644 content/ko/docs/tasks/extend-kubernetes/_index.md create mode 100644 content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 62fd283b2f..7d5e86837e 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -43,7 +43,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. 이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다. -이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/control-plane-node-communication/#ssh-터널)을 +이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을 사용한다. 마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 7fb92302f9..eab7eb0de2 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -20,8 +20,6 @@ weight: 10 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}} 그리고 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 포함된다. - - ## 관리 @@ -336,5 +334,5 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 * [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다. * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 섹션을 읽어본다. -* [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다. +* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다. * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index c21e17e3ec..cde1b093b5 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -55,14 +55,14 @@ no_list: true * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다. -* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. +* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. * [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다. ### kubelet 보안 - * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) + * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/) + * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ## 선택적 클러스터 서비스 diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 1838688d38..067ebab037 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -5,35 +5,30 @@ content_type: concept - 애드온은 쿠버네티스의 기능을 확장한다. 이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. 각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다. - - - ## 네트워킹과 네트워크 폴리시 - * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다. * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. -* [Contiv](http://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](http://github.com/contiv)이다. [인스톨러](http://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. -* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. +* [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. -* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. +* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. ## 서비스 검색 diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 3d5ba7e9d0..9c1c556808 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -8,8 +8,6 @@ weight: 30 이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에 대해 설명한다. - - ### kubeadm [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다. @@ -45,8 +43,10 @@ controllerManager: mountPath: "/etc/kubernetes/cloud.conf" ``` -인-트리 클라우드 제공자는 일반적으로 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) -및 [kubelet](/docs/admin/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다. +인-트리 클라우드 제공자는 일반적으로 +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +및 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다. 각 제공자에 대해 `--cloud-config` 에 지정된 파일의 내용도 아래에 설명되어 있다. 모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나, @@ -358,12 +358,9 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet] `extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id` 를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에 걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은 - 노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서 [kubenet]을 사용하는 데 - 필요하다. - -[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet - - + 노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서 + [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을 + 사용하는 데 필요하다. ## OVirt diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 4f516ed41e..4896a8e7b8 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -10,9 +10,6 @@ weight: 60 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다. - - - 클러스터-레벨 로깅 아키텍처는 로깅 백엔드가 @@ -132,7 +129,7 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법으로, 이는 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문이다. 그러나, 노드-레벨 로깅은 _애플리케이션의 표준 출력과 표준 에러에 대해서만 작동한다_ . -쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/user-guide/logging/stackdriver)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다. +쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/tasks/debug-application-cluster/logging-stackdriver/)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다. ### 로깅 에이전트와 함께 사이드카 컨테이너 사용 @@ -239,7 +236,7 @@ fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-containe {{< note >}} fluentd의 구성은 이 문서의 범위를 벗어난다. fluentd를 구성하는 것에 대한 자세한 내용은, -[공식 fluentd 문서](http://docs.fluentd.org/)를 참고한다. +[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다. {{< /note >}} 두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index c2835e78cb..be5befdbd3 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -8,9 +8,6 @@ weight: 40 애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여, 애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는 [구성 파일](/ko/docs/concepts/configuration/overview/)과 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다. - - - ## 리소스 구성 구성하기 @@ -321,7 +318,7 @@ metadata: kubectl scale deployment/my-nginx --replicas=1 ``` ```shell -deployment.extensions/my-nginx scaled +deployment.apps/my-nginx scaled ``` 이제 디플로이먼트가 관리하는 파드가 하나만 있다. @@ -354,7 +351,8 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled ### kubectl apply -구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며([코드로서의 구성](http://martinfowler.com/bliki/InfrastructureAsCode.html) 참조), +구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며 +([코드로서의 구성](https://martinfowler.com/bliki/InfrastructureAsCode.html) 참조), 그렇게 하면 구성하는 리소스에 대한 코드와 함께 버전을 지정하고 유지할 수 있다. 그런 다음, [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)를 사용하여 구성 변경 사항을 클러스터로 푸시할 수 있다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 28508d58f2..e5c492491a 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -10,14 +10,11 @@ weight: 50 문제가 있다. 1. 고도로 결합된 컨테이너 간의 통신: 이 문제는 - [파드](/ko/docs/concepts/workloads/pods/pod/)와 `localhost` 통신으로 해결된다. + {{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다. 2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다. 3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. 4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. - - - 쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로, @@ -91,7 +88,7 @@ Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Ope ### Apstra의 AOS -[AOS](http://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다. +[AOS](https://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다. AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다. @@ -99,7 +96,7 @@ AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워 AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다. -AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. http://www.apstra.com/products/how-it-works/ +AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. https://www.apstra.com/products/how-it-works/ ### 쿠버네티스용 AWS VPC CNI @@ -121,7 +118,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht 빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다. -가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. +가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. ### 실리움(Cilium) @@ -133,7 +130,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht ### 화웨이의 CNI-Genie -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](http://docs.projectcalico.org/), [로마나(Romana)](http://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다. +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다. CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다. @@ -155,11 +152,11 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브 ### 콘티브(Contiv) -[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](http://contiv.io)는 모두 오픈소스이다. +[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다. ### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric) -[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다. +[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다. ### DANM @@ -240,7 +237,7 @@ sysctl net.ipv4.ip_forward=1 ### Kube-router -[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다. +[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다. ### L2 네트워크 및 리눅스 브릿지 @@ -250,8 +247,8 @@ sysctl net.ipv4.ip_forward=1 철저히 테스트되지 않았다. 이 기술을 사용하여 프로세스를 완료한 경우, 알려주길 바란다. -Lars Kellogg-Stedman이 제공하는 [이 훌륭한 -튜토리얼](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의 +Lars Kellogg-Stedman이 제공하는 +[이 훌륭한 튜토리얼](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의 "With Linux Bridge devices" 섹션을 참고한다. ### Multus(멀티 네트워크 플러그인) @@ -272,7 +269,7 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// ### Nuage Networks VCS(가상 클라우드 서비스) -[Nuage](http://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다. +[Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다. Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다. @@ -292,7 +289,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 ### 프로젝트 캘리코 -[프로젝트 캘리코](http://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다. +[프로젝트 캘리코](https://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다. 캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다. @@ -300,7 +297,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 ### 로마나 -[로마나](http://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. +[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. ### Weaveworks의 위브넷 @@ -310,13 +307,9 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며, 두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다. - - ## {{% heading "whatsnext" %}} - 네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은 [네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에 자세히 설명되어 있다. - diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 3b339ca18f..8e025addd3 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -224,7 +224,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 - 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호 - immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 -이 기능을 사용하려면 `ImmutableEmphemeralVolumes` +이 기능을 사용하려면 `ImmutableEphemeralVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. ```yaml diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 42036c7da8..99e5c27298 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -132,11 +132,9 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql + - name: app + image: images.my-company.example/app:v4 env: - - name: MYSQL_ROOT_PASSWORD - value: "password" resources: requests: memory: "64Mi" @@ -144,8 +142,8 @@ spec: limits: memory: "128Mi" cpu: "500m" - - name: wp - image: wordpress + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" @@ -330,18 +328,15 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" + - name: app + image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" - - name: wp - image: wordpress + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" @@ -757,4 +752,4 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기 -* XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 +* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 387a794a6b..eb7aa1ff93 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -71,7 +71,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 ## 컨테이너 이미지 -[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/admin/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다. +[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다. - `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다. diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md index e0d6317b29..da165814da 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -252,7 +252,7 @@ spec: #### 선점 피해자의 정상적인 종료 파드가 축출되면, 축출된 피해자 파드는 -[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)을 가진다. +[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)을 가진다. 피해자 파드는 작업을 종료하고 빠져나가는 데(exit) 많은 시간을 가진다. 그렇지 않으면, 파드는 강제종료(kill) 된다. 이 정상적인 종료 기간은 스케줄러가 파드를 축출하는 지점과 보류 중인 파드(P)를 노드(N)에서 스케줄링할 수 있는 시점 사이의 @@ -265,7 +265,7 @@ spec: #### PodDisruptionBudget을 지원하지만, 보장하지 않음 -[Pod Disruption Budget(PDB)](/ko/docs/concepts/workloads/pods/disruptions/)은 +[Pod Disruption Budget](/ko/docs/concepts/workloads/pods/disruptions/)(PDB)은 애플리케이션 소유자가 자발적 중단에서 동시에 다운된 복제된 애플리케이션의 파드 수를 제한할 수 있다. 쿠버네티스는 파드를 선점할 때 PDB를 지원하지만, PDB를 따르는 것이 최선의 노력이다. 스케줄러는 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000..5b95d9a484 --- /dev/null +++ b/content/ko/docs/concepts/configuration/secret.md @@ -0,0 +1,1268 @@ +--- +title: 시크릿(Secret) +content_type: concept +feature: + title: 시크릿과 구성 관리 + description: > + 사용자의 이미지를 다시 빌드하거나 스택 구성의 시크릿을 노출하지 않고 시크릿과 애플리케이션 구성을 배포하고 업데이트한다. +weight: 30 +--- + + + +쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 +민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 +{{< glossary_tooltip term_id="pod" text="파드" >}} 정의나 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} 내에 그대로 두는 것보다 안전하고 유연하다. 자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. + + + + + +## 시크릿 개요 + +시크릿은 비밀번호, 토큰 또는 키와 같은 소량의 +민감한 데이터를 포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 +파드 명세 또는 이미지에 포함될 수 있다. 사용자는 시크릿을 생성할 수 있으며 시스템도 +일부 시크릿을 생성한다. + +시크릿을 사용하려면, 파드가 시크릿을 참조해야 한다. +시크릿은 세 가지 방법으로 파드와 함께 사용할 수 있다. + +- 하나 이상의 컨테이너에 마운트된 +{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의 +[파일](#시크릿을-파드의-파일로-사용하기)로써 사용. +- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용. +- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용. + +### 빌트인 시크릿 + +#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함 + +쿠버네티스는 API 접근을 위한 자격 증명이 포함된 +시크릿을 자동으로 생성하고 이러한 유형의 시크릿을 사용하도록 파드를 자동으로 +수정한다. + +원하는 경우 API 자격 증명의 자동 생성 및 사용을 비활성화하거나 +오버라이드할 수 있다. 그러나, API 서버에 안전하게 접근하기만 하면 되는 경우, +자동 생성 및 사용이 권장되는 워크플로이다. + +서비스 어카운트 작동 방식에 대한 자세한 내용은 +[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다. + +### 자신만의 시크릿 생성하기 + +#### `kubectl` 사용하여 시크릿 생성하기 + +시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다. +예를 들어, 데이터베이스 연결 문자열은 +사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에 +저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다. + +```shell +# 예제를 위해서 필요한 파일들을 생성한다. +echo -n 'admin' > ./username.txt +echo -n '1f2d1e2e67df' > ./password.txt +``` + +`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고 +API 서버에 오브젝트를 생성한다. +시크릿 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + +```shell +kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt +``` + +출력 결과는 다음과 비슷하다. + +``` +secret "db-user-pass" created +``` + +기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다. + +```shell +kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt +``` + +{{< note >}} +`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다. +대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다. +예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다. + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다. +{{< /note >}} + +다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다. + +```shell +kubectl get secrets +``` + +출력 결과는 다음과 비슷하다. + +``` +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s +``` + +시크릿에 대한 설명을 볼 수 있다. + +```shell +kubectl describe secrets/db-user-pass +``` + +출력 결과는 다음과 비슷하다. + +``` +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +{{< note >}} +`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지 +않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나, +터미널 로그에 저장되지 않도록 보호하기 위함이다. +{{< /note >}} + +시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다. + +#### 수동으로 시크릿 생성하기 + +먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한 +다음 해당 오브젝트를 생성할 수도 있다. +시크릿 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은 +두 개의 맵(`data` 와 `stringData`)을 +포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데 +사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은 +문자열로 제공할 수 있다. + +예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이 +문자열을 base64로 변환한다. + +```shell +echo -n 'admin' | base64 +``` + +출력 결과는 다음과 비슷하다. + +``` +YWRtaW4= +``` + +```shell +echo -n '1f2d1e2e67df' | base64 +``` + +출력 결과는 다음과 비슷하다. + +``` +MWYyZDFlMmU2N2Rm +``` + +다음과 같은 시크릿을 작성한다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다. + +```shell +kubectl apply -f ./secret.yaml +``` + +출력 결과는 다음과 비슷하다. + +``` +secret "mysecret" created +``` + +특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이 +필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며, +시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다. + +이에 대한 실질적인 예는 애플리케이션 배포 시에 +구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의 +일부를 채우려는 경우이다. + +예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우, + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "user" +password: "password" +``` + +다음 정의를 사용하여 이를 시크릿에 저장할 수 있다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: |- + apiUrl: "https://my.api.com/api/v1" + username: {{username}} + password: {{password}} +``` + +그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로 +`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다. + +`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을 +검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다. + +```shell +kubectl get secret mysecret -o yaml +``` + +출력 결과는 다음과 비슷하다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +``` + +`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면, +`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +아래의 시크릿에서 결과는 다음과 같다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +data: + username: YWRtaW5pc3RyYXRvcg== +``` + +위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다. + +`data` 와 `stringData` 의 키는 영숫자, +'-', '_' 또는 '.'로 구성되어야 한다. + +{{< note >}} +시크릿 데이터의 직렬화된 JSON 및 YAML 값은 +base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로 +생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때, +사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는 +`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에 +`-w 0` 옵션을 추가 *해야 한다*. +{{< /note >}} + +#### 생성기를 통해 시크릿 생성하기 + +쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한 +리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의 +`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후, +`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다. + +#### 파일을 통해 시크릿 생성하기 + +./username.txt 와 ./password.txt 파일에서 +`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다. + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +EOF +``` + +`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다. + +```shell +kubectl apply -k . +``` + +출력 결과는 다음과 비슷하다. + +``` +secret/db-user-pass-96mffmfh4k created +``` + +시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다. + +```shell +kubectl get secrets +``` + +출력 결과는 다음과 비슷하다. + +``` +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s +``` + +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` + +출력 결과는 다음과 비슷하다. + +``` +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +#### 문자열 리터럴(literals)을 통해 시크릿 생성하기 + +문자열 리터럴인 `username=admin` 과 `password=secret` 을 +`secretGenerator` 에 정의하여 시크릿을 만들 수 있다. + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=secret +EOF +``` + +`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다. + +```shell +kubectl apply -k . +``` + +출력 결과는 다음과 비슷하다. + +``` +secret/db-user-pass-dddghtt9b5 created +``` + +{{< note >}} +시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를 +해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은 +데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다. +{{< /note >}} + +#### 시크릿 디코딩하기 + +`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다. +예를 들어, 다음 명령을 실행하여 이전 섹션에서 +생성된 시크릿을 볼 수 있다. + +```shell +kubectl get secret mysecret -o yaml +``` + +출력 결과는 다음과 비슷하다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +`password` 필드를 디코딩한다. + +```shell +echo 'MWYyZDFlMmU2N2Rm' | base64 --decode +``` + +출력 결과는 다음과 비슷하다. + +``` +1f2d1e2e67df +``` + +#### 시크릿 편집하기 + +기존 시크릿은 다음 명령을 사용하여 편집할 수 있다. + +```shell +kubectl edit secrets mysecret +``` + +이렇게 하면 기본으로 설정된 에디터가 열리고 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다. + +```yaml +# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고, +# 빈 파일은 편집이 취소될 것이다. 이 파일을 저장하는 도중에 오류가 발생하면 +# 관련 오류와 함께 다시 열린다. +# +apiVersion: v1 +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: { ... } + creationTimestamp: 2016-01-22T18:41:56Z + name: mysecret + namespace: default + resourceVersion: "164619" + uid: cfee02d6-c137-11e5-8d73-42010af00002 +type: Opaque +``` + +## 시크릿 사용하기 + +시크릿은 데이터 볼륨으로 마운트되거나 파드의 컨테이너에서 사용할 +{{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}로 +노출될 수 있다. 또한, 시크릿은 파드에 직접 노출되지 않고, +시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, 시크릿은 +시스템의 다른 부분이 사용자를 대신해서 외부 시스템과 상호 작용하는 데 사용해야 하는 +자격 증명을 보유할 수 있다. + +### 시크릿을 파드의 파일로 사용하기 + +파드의 볼륨에서 시크릿을 사용하려면 다음과 같이 한다. + +1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다. +1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. +1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다. + +다음은 볼륨에 시크릿을 마운트하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret +``` + +사용하려는 각 시크릿은 `.spec.volumes` 에서 참조해야 한다. + +파드에 여러 컨테이너가 있는 경우, 모든 컨테이너는 +자체 `volumeMounts` 블록이 필요하지만, 시크릿에 대해서는 시크릿당 하나의 `.spec.volumes` 만 필요하다. + +많은 파일을 하나의 시크릿으로 패키징하거나, 여러 시크릿을 사용할 수 있으며, 어느 쪽이든 편리한 방법을 사용하면 된다. + +#### 특정 경로에 대한 시크릿 키 투영하기 + +시크릿 키가 투영되는 볼륨 내 경로를 제어할 수도 있다. +`.spec.volumes[].secret.items` 필드를 사용하여 각 키의 대상 경로를 변경할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username +``` + +다음과 같은 일들이 일어날 것이다. + +* `username` 시크릿은 `/etc/foo/username` 대신 `/etc/foo/my-group/my-username` 아래의 파일에 저장된다. +* `password` 시크릿은 투영되지 않는다. + +`.spec.volumes[].secret.items` 를 사용하면, `items` 에 지정된 키만 투영된다. +시크릿의 모든 키를 사용하려면, 모든 키가 `items` 필드에 나열되어야 한다. +나열된 모든 키는 해당 시크릿에 존재해야 한다. 그렇지 않으면, 볼륨이 생성되지 않는다. + +#### 시크릿 파일 퍼미션 + +단일 시크릿 키에 대한 파일 접근 퍼미션 비트를 설정할 수 있다. +만약 사용자가 퍼미션을 지정하지 않는다면, 기본적으로 `0644` 가 사용된다. +전체 시크릿 볼륨에 대한 기본 모드를 설정하고 필요한 경우 키별로 오버라이드할 수도 있다. + +예를 들어, 다음과 같은 기본 모드를 지정할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 0400 +``` + +그러고 나면, 시크릿이 `/etc/foo` 에 마운트되고 시크릿 볼륨 마운트로 생성된 +모든 파일의 퍼미션은 `0400` 이 될 것이다. + +참고로 JSON 스펙은 8진수 표기법을 지원하지 않으므로, 0400 퍼미션에 대해서 +값 256을 사용한다. 파드에 대해 JSON 대신 YAML을 사용하는 경우, 8진수 표기법을 +사용하여 보다 자연스러운 방식으로 퍼미션을 지정할 수 있다. + +참고로 파드에 `kubectl exec` 을 사용하는 경우, 예상되는 파일 모드를 찾기 위해 +심볼릭 링크를 따라가야 한다. 예를 들면, 다음과 같다. + +파드에서 시크릿 파일 모드를 확인한다. +``` +kubectl exec mypod -it sh + +cd /etc/foo +ls -l +``` + +출력 결과는 다음과 비슷하다. +``` +total 0 +lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password +lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username +``` + +올바른 파일 모드를 찾으려면 심볼릭 링크를 따라간다. + +``` +cd /etc/foo/..data +ls -l +``` + +출력 결과는 다음과 비슷하다. +``` +total 8 +-r-------- 1 root root 12 May 18 00:18 password +-r-------- 1 root root 5 May 18 00:18 username +``` + +이전 예제에서와 같이 매핑을 사용하여, 다음과 같이 +다른 파일에 대해 다른 퍼미션을 지정할 수도 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 0777 +``` + +이 경우, `/etc/foo/my-group/my-username` 에 있는 파일은 +결과적으로 `0777` 퍼미션 값을 갖게 된다. JSON을 사용하는 경우, JSON 제한으로 인해 +10진수 표기법(`511`)으로 모드를 지정해야 한다. + +참고로 이 퍼미션 값은 나중에 읽을 때 10진수 표기법으로 +표시될 수 있다. + +#### 볼륨에서 시크릿 값 사용하기 + +시크릿 볼륨을 마운트하는 컨테이너 내부에서, 시크릿 키는 파일로 +나타나고 시크릿 값은 base64로 디코딩되어 이런 파일 내에 저장된다. +다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다. + +```shell +ls /etc/foo/ +``` + +출력 결과는 다음과 비슷하다. + +``` +username +password +``` + +```shell +cat /etc/foo/username +``` + +출력 결과는 다음과 비슷하다. + +``` +admin +``` + +```shell +cat /etc/foo/password +``` + +출력 결과는 다음과 비슷하다. + +``` +1f2d1e2e67df +``` + +컨테이너의 프로그램은 파일에서 시크릿을 읽는 역할을 +한다. + +#### 마운트된 시크릿은 자동으로 업데이트됨 + +볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다. +kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다. +그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다. +캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다. +시크릿은 watch(기본값), ttl 기반 또는 단순히 API 서버로 모든 요청을 직접 +리디렉션하여 전파할 수 있다. +결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는 +순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시 +전파 지연만큼 길 수 있다. 여기서 캐시 전파 지연은 선택한 캐시 유형에 따라 +달라질 수 있다(캐시 전파 지연은 각 캐시 유형에 따라 watch 전파 지연, 캐시의 ttl, 또는 0 에 상응함). + +{{< note >}} +시크릿을 [subPath](/ko/docs/concepts/storage/volumes/#subpath-사용하기) +볼륨 마운트로 사용하는 컨테이너는 시크릿 업데이트를 +받지 않는다. +{{< /note >}} + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 +개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는 +클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면 +다음과 같은 이점이 있다. + +- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호 +- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를 +크게 줄임으로써 클러스터의 성능을 향상시킴 + +이 기능을 사용하려면, `ImmutableEphemeralVolumes` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 +시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나 +`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다. +기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을 +권장한다. +{{< /note >}} + +### 시크릿을 환경 변수로 사용하기 + +파드에서 {{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}에 +시크릿을 사용하려면 다음과 같이 한다. + +1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다. +1. 사용하려는 각 시크릿 키에 대한 환경 변수를 추가하려면 시크릿 키 값을 사용하려는 각 컨테이너에서 파드 정의를 수정한다. 시크릿 키를 사용하는 환경 변수는 시크릿의 이름과 키를 `env[].valueFrom.secretKeyRef` 에 채워야 한다. +1. 프로그램이 지정된 환경 변수에서 값을 찾도록 이미지 및/또는 커맨드 라인을 수정한다. + +다음은 환경 변수의 시크릿을 사용하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-env-pod +spec: + containers: + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + restartPolicy: Never +``` + +#### 환경 변수에서 시크릿 값 사용하기 + +환경 변수에서 시크릿을 사용하는 컨테이너 내부에서, 시크릿 키는 +시크릿 데이터의 base64 디코딩된 값을 포함하는 일반 환경 변수로 나타난다. +다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다. + +```shell +echo $SECRET_USERNAME +``` + +출력 결과는 다음과 비슷하다. + +``` +admin +``` + +```shell +echo $SECRET_PASSWORD +``` + +출력 결과는 다음과 비슷하다. + +``` +1f2d1e2e67df +``` + +### imagePullSecrets 사용하기 + +`imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다. +`imagePullSecretsDocker` 를 사용하여 도커(또는 다른 컨테이너) 이미지 레지스트리 +비밀번호가 포함된 시크릿을 kubelet에 전달할 수 있다. kubelet은 이 정보를 사용해서 파드를 대신하여 프라이빗 이미지를 가져온다. +`imagePullSecrets` 필드에 대한 자세한 정보는 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)를 참고한다. + +#### imagePullSecret 수동으로 지정하기 + +[컨테이너 이미지 문서](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)에서 `ImagePullSecrets` 지정하는 방법을 배울 수 있다. + +### imagePullSecrets가 자동으로 연결되도록 정렬하기 + +수동으로 `imagePullSecrets` 를 생성하고, 서비스어카운트(ServiceAccount)에서 +참조할 수 있다. 해당 서비스어카운트로 생성되거나 +기본적인 서비스어카운트로 생성된 모든 파드는 파드의 `imagePullSecrets` +필드를 가져오고 서비스 어카운트의 필드로 설정한다. +해당 프로세스에 대한 자세한 설명은 +[서비스 어카운트에 ImagePullSecrets 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 참고한다. + +### 수동으로 생성된 시크릿의 자동 마운트 + +수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은 +시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다. +해당 프로세스에 대한 자세한 설명은 [파드프리셋(PodPreset)을 사용하여 파드에 정보 주입하기](/docs/tasks/inject-data-application/podpreset/)를 참고한다. + +## 상세 내용 + +### 제약 사항 + +시크릿 볼륨 소스는 지정된 오브젝트 참조가 +실제로 시크릿 유형의 오브젝트를 가리키는지 확인하기 위해 유효성을 검사한다. 따라서, 시크릿에 +의존하는 모든 파드보다 먼저 시크릿을 만들어야 한다. + +시크릿 리소스는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 존재한다. +시크릿은 동일한 네임스페이스에 있는 파드에서만 참조할 수 있다. + +개별 시크릿의 크기는 1MiB로 제한된다. 이는 API 서버와 +kubelet 메모리를 소진시키는 매우 큰 시크릿 생성을 막기 위한 것이다. +그러나, 많은 작은 시크릿을 만들어도 메모리가 고갈될 수 있다. 시크릿으로 +인한 메모리 사용에 대한 보다 포괄적인 제한은 향후 버전에 계획된 기능이다. + +kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한 +시크릿 사용만 지원한다. +여기에는 `kubectl` 을 사용하거나, 레플리케이션 컨트롤러를 통해 간접적으로 생성된 모든 +파드가 포함된다. kubelet의 `--manifest-url` 플래그, `--config` 플래그 또는 +kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로 +생성된 파드는 포함하지 않는다. + +시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경 +변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을 +참조하면 파드가 시작되지 않는다. + +명명된 시크릿에 존재하지 않는 키에 대한 참조(`secretKeyRef` 필드)는 +파드가 시작되지 않도록 한다. + +잘못된 환경 변수 이름으로 간주되는 키가 있는 `envFrom` 필드로 +환경 변수를 채우는 데 사용되는 시크릿은 해당 키를 +건너뛴다. 이러면 해당 파드가 시작될 수 있다. 원인이 `InvalidVariableNames` 인 +이벤트가 발생하며 건너뛴 유효하지 않은 키 목록이 +포함된 메시지가 생성된다. 다음의 예는 2개의 유효하지 않은 +키(`1badkey` 와 `2alsobad`)가 포함된 default/mysecret을 참조하는 파드를 보여준다. + +```shell +kubectl get events +``` + +출력 결과는 다음과 비슷하다. + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### 시크릿 및 파드 수명 상호 작용 + +쿠버네티스 API를 호출하여 파드가 생성될 때, 참조된 시크릿이 있는지 확인하지 +않는다. 일단 파드가 스케줄되면, kubelet은 시크릿 값 가져오기를 +시도한다. 시크릿이 존재하지 않거나 API 서버에 대한 +일시적인 연결 부족으로 인해 시크릿을 가져올 수 없는 경우, kubelet은 +주기적으로 재시도한다. kubelet은 아직 시작되지 않은 이유를 설명하는 +파드에 대한 이벤트를 보고한다. 시크릿을 가져오면, kubelet은 +이를 포함하는 볼륨을 생성하고 마운트한다. 모든 파드의 볼륨이 +마운트될 때까지 파드의 컨테이너는 시작되지 않는다. + +## 사용 사레 + +### 사용 사례: 컨테이너 환경 변수로 사용하기 + +시크릿 정의를 작성한다. +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + USER_NAME: YWRtaW4= + PASSWORD: MWYyZDFlMmU2N2Rm +``` + +시크릿을 생성한다. +```shell +kubectl apply -f mysecret.yaml +``` + +모든 시크릿 데이터를 컨테이너 환경 변수로 정의하는 데 `envFrom` 을 사용한다. 시크릿의 키는 파드의 환경 변수 이름이 된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - secretRef: + name: mysecret + restartPolicy: Never +``` + +### 사용 사례: ssh 키가 있는 파드 + +몇 가지 ssh 키를 포함하는 시크릿을 생성한다. + +```shell +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +``` + +출력 결과는 다음과 비슷하다. + +``` +secret "ssh-key-secret" created +``` + +ssh 키를 포함하는 `secretGenerator` 필드가 있는 `kustomization.yaml` 를 만들 수도 있다. + +{{< caution >}} +사용자 자신의 ssh 키를 보내기 전에 신중하게 생각한다. 클러스터의 다른 사용자가 시크릿에 접근할 수 있다. 쿠버네티스 클러스터를 공유하는 모든 사용자가 접근할 수 있도록 하려는 서비스 어카운트를 사용하고, 사용자가 손상된 경우 이 계정을 취소할 수 있다. +{{< /caution >}} + +이제 ssh 키를 가진 시크릿을 참조하고 +볼륨에서 시크릿을 사용하는 파드를 만들 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +컨테이너의 명령이 실행될 때, 다음 위치에서 키 부분을 사용할 수 있다. + +``` +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey +``` + +그러면 컨테이너는 ssh 연결을 맺기 위해 시크릿 데이터를 자유롭게 사용할 수 있다. + +### 사용 사례: 운영 / 테스트 자격 증명이 있는 파드 + +이 예제에서는 운영 환경의 자격 증명이 포함된 시크릿을 +사용하는 파드와 테스트 환경의 자격 증명이 있는 시크릿을 사용하는 다른 파드를 +보여준다. + +사용자는 `secretGenerator` 필드가 있는 `kustomization.yaml` 을 만들거나 +`kubectl create secret` 을 실행할 수 있다. + +```shell +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 +``` + +출력 결과는 다음과 비슷하다. + +``` +secret "prod-db-secret" created +``` + +```shell +kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests +``` + +출력 결과는 다음과 비슷하다. + +``` +secret "test-db-secret" created +``` + +{{< note >}} +`$`, `\`, `*`, `=` 그리고 `!` 와 같은 특수 문자는 사용자의 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다. +대부분의 셸에서 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다. +예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다. + +```shell +kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' +``` + +파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다. +{{< /note >}} + +이제 파드를 생성한다. + +```shell +cat < pod.yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +EOF +``` + +동일한 kustomization.yaml에 파드를 추가한다. + +```shell +cat <> kustomization.yaml +resources: +- pod.yaml +EOF +``` + +다음을 실행하여 API 서버에 이러한 모든 오브젝트를 적용한다. + +```shell +kubectl apply -k . +``` + +두 컨테이너 모두 각 컨테이너의 환경에 대한 값을 가진 파일시스템에 다음의 파일이 존재한다. + +``` +/etc/secret-volume/username +/etc/secret-volume/password +``` + +두 파드의 사양이 한 필드에서만 어떻게 다른지 확인한다. 이를 통해 +공통 파드 템플릿에서 다양한 기능을 가진 파드를 생성할 수 있다. + +두 개의 서비스 어카운트를 사용하여 기본 파드 명세를 더욱 단순화할 수 있다. + +1. `prod-db-secret` 을 가진 `prod-user` +1. `test-db-secret` 을 가진 `test-user` + +파드 명세는 다음과 같이 단축된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage +``` + +### 사용 사례: 시크릿 볼륨의 도트 파일(dotfile) + +점으로 시작하는 키를 정의하여 데이터를 "숨김"으로 만들 수 있다. +이 키는 도트 파일 또는 "숨겨진" 파일을 나타낸다. 예를 들어, 다음 시크릿이 `secret-volume` 볼륨에 +마운트되면 아래와 같다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +apiVersion: v1 +kind: Pod +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: k8s.gcr.io/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +``` + +볼륨은 `.secret-file` 이라는 하나의 파일을 포함하고, +`dotfile-test-container` 는 `/etc/secret-volume/.secret-file` 경로에 +이 파일을 가지게 된다. + +{{< note >}} +`ls -l` 명령의 결과에서 숨겨진 점으로 시작하는 파일들은 +디렉터리 내용을 나열할 때 `ls -la` 를 사용해야 이 파일들을 볼 수 있다. +{{< /note >}} + +### 사용 사례: 파드의 한 컨테이너에 표시되는 시크릿 + +HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에 +서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이 +복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이 +있을 수 있으며, 이로 인해 프라이빗 키가 공격자에게 노출될 수 있다. + +이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과 +비즈니스 로직을 처리하지만, 프라이빗 키를 볼 수 없는 프론트엔드 컨테이너와 +프라이빗 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에 +응답하는 서명자 컨테이너로 나눌 수 있다. + +이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서 +파일을 읽는 것보다 다소 어려운 임의적인 어떤 작업을 수행해야 +한다. + + + +## 모범 사례 + +### 시크릿 API를 사용하는 클라이언트 + +시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC]( +/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책]( +/docs/reference/access-authn-authz/authorization/)을 +사용하여 접근를 제한해야 한다. + +시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이 +쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로 +확대될 수 있다. 개별 앱이 상호 작용할 것으로 예상되는 시크릿의 힘에 대해 추론할 수 있더라도 +동일한 네임스페이스 내의 다른 앱이 이러한 가정을 +무효화할 수 있다. + +이러한 이유로 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은 +매우 강력한 기능이며, 시크릿을 나열하면 클라이언트가 해당 네임스페이스에 +있는 모든 시크릿의 값을 검사할 수 있기 때문에 피해야 한다. 클러스터의 +모든 시크릿을 감시(`watch`)하고 나열(`list`)하는 기능은 가장 특권이 있는 시스템 레벨의 +컴포넌트에 대해서만 예약되어야 한다. + +시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을 +수행해야 한다. 이를 통해 관리자는 앱에 필요한 +[개별 인스턴스에 대한 접근을 허용 목록에 추가]( +/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을 +제한할 수 있다. + +`get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을 +참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를 +설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API]( +https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도 +제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수 +있을 것이다. + +## 보안 속성 + +### 보호 + +시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 +있으므로, 파드 생성, 보기, 편집 워크플로 중에 +시크릿이 노출될 위험이 적다. 또한 시스템은 가능한 경우 +디스크에 기록하지 않는 등 시크릿에 대한 추가 예방 조치를 +취할 수 있다. + +해당 노드의 파드에 필요한 경우에만 시크릿이 노드로 전송된다. +kubelet은 시크릿이 디스크 저장소에 기록되지 않도록 시크릿을 +`tmpfs` 에 저장한다. 일단 시크릿에 의존하는 파드가 삭제되면, kubelet은 +시크릿 데이터의 로컬 복제본도 삭제한다. + +동일한 노드의 여러 파드에 대한 시크릿이 있을 수 있다. 그러나 +파드가 요청하는 시크릿만 해당 컨테이너 내에서 잠재적으로 볼 수 있다. +따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다. + +파드에는 여러 개의 컨테이너가 있을 수 있다. 그러나, 파드의 각 컨테이너는 +컨테이너 내에서 볼 수 있도록 파드의 `volumeMounts` 에 있는 시크릿 볼륨을 +요청해야 한다. 이것은 유용한 [파드 레벨에서의 보안 +파티션](#사용-사례-파드의-한-컨테이너에-표시되는-시크릿)을 구성하는 데 사용할 수 있다. + +대부분의 쿠버네티스 배포판에서, 사용자와 API 서버 간, +API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. +이러한 채널을 통해 전송될 때 시크릿이 보호된다. + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} + +시크릿 데이터에 대해 [저장 시 암호화(encryption at rest)](/docs/tasks/administer-cluster/encrypt-data/)를 +활성화할 수 있으며, 이를 통해 보안성에 대한 보장 없이는 시크릿이 {{< glossary_tooltip term_id="etcd" >}}에 저장되지 않도록 한다 . + +### 위험 + + - API 서버에서 시크릿 데이터는 {{< glossary_tooltip term_id="etcd" >}}에 저장된다. + 따라서, + - 관리자는 클러스터 데이터에 대해 저장 시 암호화를 활성화해야 한다. (v1.13 이상 필요) + - 관리자는 etcd에 대한 접근을 admin 사용자로 제한해야 한다. + - 관리자는 더 이상 사용하지 않을 때 etcd에서 사용하는 디스크를 지우거나 폐기할 수 있다. + - 클러스터에서 etcd를 실행하는 경우, 관리자는 etcd peer-to-peer 통신에 대해 + SSL/TLS를 사용해야 한다. + - base64로 인코딩된 시크릿 데이터가 있는 매니페스트(JSON 또는 YAML) + 파일을 통해 시크릿을 구성하는 경우, 이 파일을 공유하거나 소스 리포지터리에 + 체크인하면 시크릿이 손상된다. Base64 인코딩은 암호화 방법이 _아니며_ + 일반 텍스트와 동일한 것으로 간주된다. + - 실수로 기록하거나 신뢰할 수 없는 상대방에게 전송하지 않는 것과 같이, + 애플리케이션은 볼륨에서 읽은 후에 시크릿 값을 보호해야 한다. + - 시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다. + API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는 + 시크릿을 노출하는 파드를 실행할 수 있다. + - 현재, 모든 노드에 대한 루트 권한이 있는 모든 사용자는 kubelet을 가장하여 + API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의 + 영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된 + 기능이다. diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 799306a9ff..c6cb09965a 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -25,7 +25,7 @@ weight: 20 컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다. 그것은 `hostname` 커맨드 또는 libc의 -[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) +[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 함수 호출을 통해서 구할 수 있다. 파드 이름과 네임스페이스는 @@ -48,7 +48,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` -서비스에 지정된 IP 주소가 있고 [DNS 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. +서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index ac29c19c1b..0fe4bb9b9d 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로 파라미터는 핸들러에 전달되지 않는다. 종료 동작에 더 자세한 대한 설명은 -[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다. +[파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다. ### 훅 핸들러 구현 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 0f7bb0cb13..f17841027b 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -262,7 +262,7 @@ EOF 이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다. -그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에 +그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-accounts/)) 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다. 자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 29d8672fca..e6d64bdfb7 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -19,9 +19,6 @@ no_list: true 어떤 익스텐션(extension) 포인트와 패턴이 있는지, 그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. - - - ## 개요 @@ -32,14 +29,14 @@ no_list: true *구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). 호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. -[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다. ## 익스텐션 @@ -71,7 +68,7 @@ no_list: true 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: -[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 +[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -93,12 +90,12 @@ kubectl에서 1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. -2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. -3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. -4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다. +3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다. 5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. -6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. -7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. +6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. +7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다. 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. @@ -173,14 +170,14 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 ### 네트워크 플러그인 -노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. +노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. ### 스케줄러 익스텐션 스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 기본 스케줄러를 완전히 교체하거나, -[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를 +[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를 동시에 실행할 수 있다. 이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 @@ -191,9 +188,6 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 [웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 지원한다. - - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index db2eddb3d1..fd8f2c0107 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -11,8 +11,6 @@ weight: 10 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다. - - ## 애그리게이션 레이어 @@ -30,11 +28,8 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 `EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다. - - ## {{% heading "whatsnext" %}} - * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). * 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 159c0fc846..18b98db97c 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -10,8 +10,6 @@ weight: 10 커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를 추가하는 두 가지 방법과 이들 중에서 선택하는 방법에 대해 설명한다. - - ## 커스텀 리소스 @@ -49,7 +47,9 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 ## 쿠버네티스 클러스터에 커스텀 리소스를 추가해야 하나? -새로운 API를 생성할 때 [쿠버네티스 클러스터 API와 생성한 API를 애그리게이트](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)할 것인지 아니면 생성한 API를 독립적으로 유지할 것인지 고려하자. +새로운 API를 생성할 때 +[쿠버네티스 클러스터 API와 생성한 API를 애그리게이트](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)할 것인지 +아니면 생성한 API를 독립적으로 유지할 것인지 고려하자. | API 애그리게이트를 고려할 경우 | 독립 API를 고려할 경우 | | ---------------------------- | ---------------------------- | 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 bfdb7ef8c3..2c57af0b5d 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 @@ -18,8 +18,6 @@ weight: 20 및 공급 업체별 초기화 및 설정이 필요할 수 있는 기타 유사한 컴퓨팅 리소스가 포함된다. - - ## 장치 플러그인 등록 @@ -38,9 +36,9 @@ service Registration { * 유닉스 소켓의 이름. * 빌드된 장치 플러그인 API 버전. * 알리려는 `ResourceName`. 여기서 `ResourceName` 은 - [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 - `vendor-domain/resourcetype` 의 형식으로 따라야 한다. - (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) + [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 + `vendor-domain/resourcetype` 의 형식으로 따라야 한다. + (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.) 성공적으로 등록하고 나면, 장치 플러그인은 kubelet이 관리하는 장치 목록을 전송한 다음, kubelet은 kubelet 노드 상태 업데이트의 일부로 diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index 543b5cfa48..8a98d9bd28 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -12,14 +12,14 @@ weight: 10 이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. 쿠버네티스 클러스터를 업무 환경의 요구에 맞게 -조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. -잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 +조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 +대상으로 한다. +잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 +쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 어떤 익스텐션 포인트와 패턴이 있는지, 그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. - - ## 개요 @@ -30,14 +30,14 @@ weight: 10 *구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). 호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. -[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. ## 익스텐션(Extension) {#익스텐션} @@ -69,7 +69,7 @@ weight: 10 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: -[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 +[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -90,13 +90,13 @@ kubectl에서 -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. -2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. -3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. -4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. -5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. -6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. -7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. +3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. +6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. +7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. @@ -157,7 +157,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### 스토리지 플러그인 -[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 +[Flex Volumes](/ko/docs/concepts/storage/volumes/#flexVolume)을 사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. @@ -168,17 +168,17 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 발견할 수 있게 해준다. - ### 네트워크 플러그인 -노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. +노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 +다양한 네트워킹 패브릭을 지원할 수 있다. ### 스케줄러 익스텐션 스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 기본 스케줄러를 완전히 교체하거나, -[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를 +[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를 동시에 실행할 수 있다. 이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 @@ -190,11 +190,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 지원한다. - - ## {{% heading "whatsnext" %}} - * [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 * 인프라스트럭처 익스텐션에 대해 더 알아보기 diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index c663964e21..bcd9bb9945 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -11,9 +11,6 @@ weight: 30 사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는 쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다. - - - ## 동기 부여 diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md new file mode 100644 index 0000000000..6e27220d68 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -0,0 +1,236 @@ +--- +title: 서비스 카탈로그 +content_type: concept +weight: 40 +--- + + +{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}} + +[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다. +매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다. + +{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다. + + + + + +## 유스케이스 예제 + +한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다. +그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다. +다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다. + +클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다. +따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다. +애플리케이션은 그것을 서비스로 간단하게 사용할 수 있다. + +## 아키텍처 + +서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다. + +스토리지에 etcd를 사용하여 확장 API 서버와 컨트롤러로 구현된다. 또한 쿠버네티스 1.7 이상에서 제공하는 [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하여 API를 제공한다. + +
+ +![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg) + + +### API 리소스 + +서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다. + +* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표. +이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다. +* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스. +새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다. +* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다. +* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스. +클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다. +새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다. +* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다. +자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다. +서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다. + +### 인증 + +서비스 카탈로그는 다음의 인증 방법을 지원한다. + +* 기본 (username/password) +* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750) + +## 사용법 + +클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다. + +1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열. +1. 매니지드 서비스의 새 인스턴스 프로비저닝. +1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩. +1. 연결 자격 증명을 애플리케이션에 매핑. + +### 매니지드 서비스와 서비스 플랜 나열 + +먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다. + +다음은 `ClusterServiceBroker` 리소스 예시이다. + +```yaml +apiVersion: servicecatalog.k8s.io/v1beta1 +kind: ClusterServiceBroker +metadata: + name: cloud-broker +spec: + # 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.) + url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default + ##### + # bearer 토큰 정보 혹은 TLS용 caBundle과 같은 + # 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다. + ##### +``` + +다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다. + +![List Services](/images/docs/service-catalog-list.svg) + +1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다. +1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다. +1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다. + + kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName + + 아래와 같은 형태의 서비스 이름 목록이 출력된다. + + SERVICE NAME EXTERNAL NAME + 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service + ... ... + + 또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다. + + kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName + + 아래와 같은 형태의 플랜 이름 목록이 출력된다. + + PLAN NAME EXTERNAL NAME + 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name + ... ... + + +### 새 인스턴스 프로비저닝 + +클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다. + +다음은 `ServiceInstance` 리소스의 예시이다. + +```yaml +apiVersion: servicecatalog.k8s.io/v1beta1 +kind: ServiceInstance +metadata: + name: cloud-queue-instance + namespace: cloud-apps +spec: + # 이전에 반환된 서비스 중 하나를 참조 + clusterServiceClassExternalName: cloud-provider-service + clusterServicePlanExternalName: service-plan-name + ##### + # 이곳에 서비스 브로커가 사용할 수 있는 + # 파라미터를 추가할 수 있다. + ##### +``` + +다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다. + +![Provision a Service](/images/docs/service-catalog-provision.svg) + +1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다. +1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다. +1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다. + +### 매니지드 서비스에 바인딩 + +새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다. + +다음은 `ServiceBinding` 리소스의 예시다. + +```yaml +apiVersion: servicecatalog.k8s.io/v1beta1 +kind: ServiceBinding +metadata: + name: cloud-queue-binding + namespace: cloud-apps +spec: + instanceRef: + name: cloud-queue-instance + ##### + # 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의 + # 추가 정보를 여기에 추가할 수 있다. + ##### +``` + +다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다. + +![Bind to a managed service](/images/docs/service-catalog-bind.svg) + +1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다. +1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다. +1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다. + +### 연결 자격 증명 매핑 + +바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다. +이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다. + +
+ +![Map connection credentials](/images/docs/service-catalog-map.svg) + +#### 파드 구성 파일 + +이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다. + +다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다. + +```yaml +... + spec: + volumes: + - name: provider-cloud-key + secret: + secretName: sa-key + containers: +... + volumeMounts: + - name: provider-cloud-key + mountPath: /var/secrets/provider + env: + - name: PROVIDER_APPLICATION_CREDENTIALS + value: "/var/secrets/provider/key.json" +``` + +다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다. + + +```yaml +... + env: + - name: "TOPIC" + valueFrom: + secretKeyRef: + name: provider-queue-credentials + key: topic +``` + + + + +## {{% heading "whatsnext" %}} + +* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. +* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 +* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 프로젝트 탐색 +* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 + + + + + diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 26047a8814..8ce410330c 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -22,9 +22,6 @@ card: API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다. - - - ## API 변경 @@ -84,7 +81,7 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. ## API 버전 규칙 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, -쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 +쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. 버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를 @@ -156,14 +153,6 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 {{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와 controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}} -## extensions/v1beta1 그룹 내 특정 리소스 활성화하기 - -데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크폴리시, 파드시큐리티폴리시 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다. -예시: 디플로이먼트와 데몬셋의 활성화 설정은 -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다. - -{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} - ## 지속성 쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에 diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 73fa4ff4d0..c43acf468c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -92,5 +92,5 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. -* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. +* [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index ed896ce005..a007375673 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -20,10 +20,9 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 } ``` -레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. - - - +레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 +적합하다. 식별되지 않는 정보는 +[어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. @@ -183,7 +182,10 @@ kubectl get pods -l 'environment,environment notin (frontend)' ### API 오브젝트에서 참조 설정 -[`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다. +[`services`](/ko/docs/concepts/services-networking/service/) 와 +[`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 +일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 +[파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다. #### 서비스와 레플리케이션 컨트롤러 @@ -208,7 +210,11 @@ selector: #### 세트-기반 요건을 지원하는 리소스 -[`Job`](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. +[`Job`](/ko/docs/concepts/workloads/controllers/job/), +[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/), +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 +[`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 +새로운 리소스들은 _집합성 기준_ 의 요건도 지원한다. ```yaml selector: @@ -226,4 +232,3 @@ selector: 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다. - diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index ec4df0668d..3d11774cce 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -9,9 +9,6 @@ weight: 30 쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다. 이런 가상 클러스터를 네임스페이스라고 한다. - - - ## 여러 개의 네임스페이스를 사용하는 경우 @@ -32,12 +29,13 @@ weight: 30 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를 -구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다. +구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 +사용한다. ## 네임스페이스 다루기 -네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 -기술되어 있다. +네임스페이스의 생성과 삭제는 +[네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. {{< note >}} 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. @@ -89,7 +87,7 @@ kubectl config view --minify | grep namespace: ## 네임스페이스와 DNS -[서비스](/docs/user-guide/services)를 생성하면 해당 +[서비스](/ko/docs/concepts/services-networking/service/)를 생성하면 해당 [DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다. 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데, 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다. @@ -100,7 +98,8 @@ kubectl config view --minify | grep namespace: 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. -그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 +그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 +퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다. 다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다. @@ -113,8 +112,6 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` - - ## {{% heading "whatsnext" %}} * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 590116af6f..4a999c6faa 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -10,7 +10,6 @@ weight: 15 제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다. - ## 관리 기법 @@ -167,11 +166,8 @@ kubectl apply -R -f configs/ - 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다. - diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다. - - ## {{% heading "whatsnext" %}} - - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index 84656375c0..8a8270be8c 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -6,13 +6,10 @@ weight: 10 -기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다. +기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)로 실행된다. 리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. - - - _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. @@ -52,11 +49,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다. - - ## {{% heading "whatsnext" %}} - 자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다. 제한의 사용에 대한 예시는 다음을 참조한다. @@ -67,5 +61,3 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). - [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). - [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/). - - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index c0ccaea504..a81038e444 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -11,9 +11,6 @@ weight: 20 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 부여할 수 있다. - - - ## 파드 시큐리티 폴리시란? @@ -140,7 +137,7 @@ RBAC 바인딩에 대한 자세한 예는, ### 문제 해결 -- [컨트롤러 관리자](/docs/admin/kube-controller-manager/)는 +- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는 [보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며, 슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고, 모든 파드시큐리티폴리시 오브젝트가 허용되며 @@ -626,13 +623,9 @@ spec: - `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다. [Sysctl 문서]( -/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다. - - +/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다. ## {{% heading "whatsnext" %}} - -폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. - -API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. +- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. +- API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index ca1af3adc2..13107a0613 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -11,9 +11,6 @@ weight: 10 리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다. - - - `ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 @@ -25,15 +22,21 @@ weight: 10 - 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 적용하기 위한 지원이 계획되어 있다. + - 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다. + - 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은 사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. + - 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는 메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다. + - `cpu`, `memory`와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우 사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이 파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 `LimitRanger` 어드미션 컨트롤러를 사용하자. - 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. + + 이 문제를 회피하는 방법에 대한 예제는 + [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. `ResourceQuota` 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. @@ -61,7 +64,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 ## 컴퓨트 리소스 쿼터 -지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/docs/user-guide/compute-resources) 합을 제한할 수 있다. +지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 합을 제한할 수 있다. 다음과 같은 리소스 유형이 지원된다. @@ -594,9 +597,6 @@ plugins: [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다. - - ## {{% heading "whatsnext" %}} - -자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. +- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 3c0a4c5110..a306a26a23 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -10,8 +10,6 @@ weight: 10 파드를 실행할 수 있도록 {{< glossary_tooltip text="파드" term_id="pod" >}}가 {{< glossary_tooltip text="노드" term_id="node" >}}에 적합한지 확인하는 것을 말한다. - - ## 스케줄링 개요 {#scheduling} @@ -92,6 +90,6 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 +* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 1993fc860d..97345c0efb 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를 지원한다. 전자는 기본적으로 작동하지만 후자는 -[CoreDNS 클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다. +[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다. {{< note >}} 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성, 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 3f5a05f4ee..927201d90c 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -65,10 +65,19 @@ SRV 레코드는 노멀 서비스 또는 ### A/AAAA 레코드 -디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은 -DNS 주소를 갖게 된다. +일반적으로 파드에는 다음과 같은 DNS 주소를 갖는다. -`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` +`pod-ip-address.my-namespace.pod.cluster-domain.example`. + +예를 들어, `default` 네임스페이스의 파드에 IP 주소 172.17.0.3이 있고, +클러스터의 도메인 이름이 `cluster.local` 이면, 파드는 다음과 같은 DNS 주소를 갖는다. + +`172-17-0-3.default.pod.cluster.local`. + +서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된 +모든 파드는 다음과 같은 DNS 주소를 갖는다. + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. ### 파드의 hostname 및 subdomain 필드 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 47d2687dee..5d6dbefafe 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -26,7 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. -* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. +* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. * [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 VMware에서 제공하고 지원한다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 23ab2d1ade..b5cf1df0ce 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -429,7 +429,7 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 얻을 수 있다. 또한, 헬스 체크를 인그레스를 통해 직접 노출되지 않더라도, 쿠버네티스에는 -[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)와 +[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)와 같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이 있다는 점도 주목할 가치가 있다. 컨트롤러 별 설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다( diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index adcf9f9e9a..4d8bb47bda 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -4,8 +4,6 @@ content_type: concept weight: 50 --- -{{< toc >}} - 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 429708e4bf..90ec166c03 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -18,8 +18,6 @@ weight: 10 쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다. - - ## 동기 @@ -388,7 +386,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다. 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다. [도커 링크 호환](https://docs.docker.com/userguide/dockerlinks/) 변수 -([makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와 +([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고, 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다. @@ -752,7 +750,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지 `443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히 프록시만 하는 HTTP이다. -쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다. +쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다. 사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다. ```bash @@ -887,7 +885,7 @@ AWS에서 네트워크 로드 밸런서를 사용하려면, `nlb` 값이 설정 ``` {{< note >}} -NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 [AWS 문서](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) +NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 [AWS 문서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets) 를 참고한다. {{< /note >}} @@ -1044,8 +1042,8 @@ spec: ## 단점 VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일에서는 동작하지만, 수천 개의 -서비스가 포함된 대규모 클러스터로는 확장되지 않는다. [포털에 대한 -독창적인 설계 제안](http://issue.k8s.io/1107)에 이에 대한 자세한 내용이 +서비스가 포함된 대규모 클러스터로는 확장되지 않는다. +[포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이 있다. 유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index c5a09d23e9..71e78eae96 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -13,9 +13,6 @@ weight: 20 이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. - - - ## 소개 @@ -142,7 +139,11 @@ Events: 기본 볼륨 플러그인에서 지원하는 경우 `Recycle` 반환 정책은 볼륨에서 기본 스크럽(`rm -rf /thevolume/*`)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다. -그러나 관리자는 [여기](/docs/admin/kube-controller-manager/)에 설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를 사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다. 사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가 포함되어야 한다. +그러나 관리자는 [레퍼런스](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 +설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를 +사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다. +사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가 +포함되어야 한다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 7df975db14..69b74ddefe 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -10,8 +10,6 @@ weight: 30 [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes)에 익숙해지는 것을 권장한다. - - ## 소개 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index c93cc5018e..f57a003d13 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -15,9 +15,6 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. - - - ## 배경 @@ -95,7 +92,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ### awsElasticBlockStore {#awselasticblockstore} `awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS -볼륨](http://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 +볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" @@ -396,8 +393,8 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이 ### gcePersistentDisk {#gcepersistentdisk} -`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) [퍼시스턴트 -디스크](http://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 +`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) +[퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다. @@ -532,7 +529,7 @@ spec: ### glusterfs {#glusterfs} -`glusterfs` 볼륨을 사용하면 [Glusterfs](http://www.gluster.org) (오픈 +`glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 @@ -583,7 +580,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 사용되는 리소스를 설명할 수 없다. * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. - 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서 + 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/tasks/configure-pod-container/security-context/)에서 루트로 실행하거나 `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. @@ -960,8 +957,8 @@ CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장 ### rbd {#rbd} -`rbd` 볼륨을 사용하면 [Rados Block -Device](http://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 +`rbd` 볼륨을 사용하면 +[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를 @@ -1038,7 +1035,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 업데이트를 수신하지 못한다. {{< /note >}} -시크릿에 대해서 [여기](/docs/user-guide/secrets)에 더 자세한 설명이 있다. +시크릿에 대해서 [여기](/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다. ### storageOS {#storageos} @@ -1237,12 +1234,13 @@ spec: 사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간 격리는 없다. -앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/docs/user-guide/compute-resources) +앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이 있는 클러스터에 사용할 매체 유형을 선택할 수 있을 것으로 기대한다. ## 아웃 오브 트리 볼륨 플러그인 + 아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고 FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. @@ -1318,7 +1316,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes` 필드에서 반환되는 매핑과 일치해야 한다. 이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, - 그리고 `NodePublishVolumeRequest` 의 `volume_attributes` 필드를 + 그리고 `NodePublishVolumeRequest` 의 `volume_context` 필드를 통해 CSI 드라이버로 전달된다. - `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` 그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index c06a43edf6..dca5a651f4 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -20,9 +20,6 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. - - - ## 데몬셋 사양 작성 @@ -42,7 +39,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 필수 필드 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/), +일반적인 설정파일 작업에 대한 정보는 +[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 데몬셋 오브젝트의 이름은 유효한 @@ -54,7 +52,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다. 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). @@ -65,7 +63,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 파드 셀렉터 `.spec.selector` 필드는 파드 셀렉터이다. 이것은 -[잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다. +[잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다. 쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. 파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다. diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 91b20304c7..e782c7c60d 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1,6 +1,4 @@ --- - - title: 디플로이먼트 feature: title: 자동화된 롤아웃과 롤백 @@ -13,18 +11,15 @@ weight: 30 -_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 -[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. +_디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id="pod" >}}와 +{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}에 대한 선언적 업데이트를 제공한다. -디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. +디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}}는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. {{< note >}} 디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다. {{< /note >}} - - - ## 유스케이스 @@ -1042,7 +1037,8 @@ echo $? ## 디플로이먼트 사양 작성 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. -설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +설정 파일 작업에 대한 일반적인 내용은 +[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. @@ -1053,8 +1049,8 @@ echo $? `.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. -이것은 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. +이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다. 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다. 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다. @@ -1155,10 +1151,6 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 이 기본 값은 0이다(파드는 준비되는 즉시 사용할 수 있는 것으로 간주됨). 파드가 준비되었다고 간주되는 시기에 대한 자세한 내용은 [컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참조한다. -### 롤백 대상 - -`.spec.rollbackTo` 필드는 API 버전 `extensions/v1beta1` 과 `apps/v1beta1` 에서 사용되지 않는다. `apps/v1beta2` 로 시작하는 API 버전에서는 더 이상 지원되지 않는다. 대신, [이전 수정 버전으로 롤백](#이전-수정-버전으로-롤백)에서 소개한 `kubectl rollout undo` 를 사용해야 한다. - ### 수정 버전 기록 제한 디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다. diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index 03083b86ed..902326a9a4 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -111,12 +111,6 @@ metadata: 인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan", "Foreground" 또는 "Background" 이다. -쿠버네티스 1.9 이전에는 많은 컨트롤러의 리소스에 대한 기본 가비지 수집 정책이 `orphan` 이었다. -여기에는 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋 그리고 -디플로이먼트가 포함된다. 그룹 버전 `extensions/v1beta1`, `apps/v1beta1` 그리고 `apps/v1beta2` 의 kinds에서는 -달리 지정하지 않는 한 오브젝트가 분리되는 것이 기본이다. 쿠버네티스 1.9에서는 그룹 버전 `apps/v1` 의 모든 kinds에 해당하는 -종속 오브젝트들이 기본적으로 삭제된다. - 여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다. ```shell diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 7b48a96c67..a77678a975 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -21,9 +21,6 @@ weight: 70 잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다. - - - ## 예시 잡 실행하기 @@ -119,7 +116,7 @@ kubectl logs $pods `.spec.template` 은 `.spec` 의 유일한 필수 필드이다. -`.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확하게 같은 스키마를 가지고 있다. +`.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 같은 스키마를 가지고 있다. 추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한 레이블([파드 셀렉터](#파드-셀렉터)를 본다)과 적절한 재시작 정책을 명시해야 한다. @@ -211,7 +208,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에 재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과 관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...) -한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 +한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프 카운트가 재설정된다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index c2414d9fdd..e800a253d7 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -20,9 +20,6 @@ _레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다. - - - ## 레플리케이션 컨트롤러의 동작방식 @@ -123,7 +120,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿) 이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. @@ -131,7 +128,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 만 허용되며, 특별히 지정되지 않으면 기본값이다. 로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다. -예를 들어 [Kubelet](/docs/admin/kubelet/) 혹은 도커이다. +예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다. ### 레플리케이션 컨트롤러에서 레이블 @@ -211,7 +208,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다. -[#1353](http://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다. +[#1353](https://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다. 이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다. @@ -236,11 +233,11 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 ## 레플리케이션 컨트롤러의 책임 -레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](http://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. +레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다. -레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](http://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](http://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](http://issue.k8s.io/170)) 까지도 고려해야 한다. +레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170)) 까지도 고려해야 한다. -레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다. +레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다. ## API 오브젝트 @@ -280,4 +277,4 @@ API 오브젝트에 대한 더 자세한 것은 ## 더 자세한 정보는 -[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다. +[스테이트리스 애플리케이션 디플로이먼트 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 3d110ee6c6..a941266230 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -18,12 +18,6 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 kube-apiserver와 kube-controller-manager와 함께 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. - - - - - - ## TTL 컨트롤러 @@ -80,7 +74,6 @@ TTL 컨트롤러는 쿠버네티스 리소스에 ## {{% heading "whatsnext" %}} +* [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리) -[자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) - -[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) +* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 35ded5ad4a..42e0b14607 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,269 @@ --- -title: "파드" +title: 파드 +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + + + +_파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. + +_파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의 +{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다. +이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, +함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는 +애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 +애플리케이션 컨테이너가 포함된다. +클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다. + +애플리케이션 컨테이너와 마찬가지로, 파드에는 +파드 시작 중에 실행되는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가 +포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해 +[임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 +삽입할 수도 있다. + + + +## 파드란 무엇인가? + +{{< note >}} +[도커](https://www.docker.com/)가 가장 일반적으로 +잘 알려진 런타임이지만, 쿠버네티스는 도커보다 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 +더 많이 지원하며, 도커의 일부 용어를 사용하면 파드를 설명하는 데 도움이 된다. +{{< /note >}} + +파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 +도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. +파드의 콘텍스트 내에서 개별 애플리케이션은 +추가적으로 하위 격리가 적용된다. + +도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 +있는 도커 컨테이너 그룹과 비슷하다. + +## 파드의 사용 + +일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)" +term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다. +파드가 상태를 추적해야 한다면, +{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 리소스를 고려한다. + +쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다. + +* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은 + 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 + 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 + 파드를 관리한다. +* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는 + 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 + 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 + 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 + 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 _사이드카_ 컨테이너는 + 해당 파일을 새로 고치거나 업데이트한다. + 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 + 단일 단위로 함께 래핑한다. + + {{< note >}} + 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은 + 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된 + 특정 인스턴스에서만 사용해야 한다. + {{< /note >}} + +각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은 +인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을 +수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다. +쿠버네티스에서는 이를 일반적으로 _레플리케이션_ 이라고 한다. +복제된 파드는 일반적으로 워크로드 리소스와 +해당 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에 의해 그룹으로 생성되고 관리된다. + +쿠버네티스가 워크로드 리소스와 해당 컨트롤러를 사용하여 애플리케이션 스케일링과 +자동 복구를 구현하는 방법에 대한 자세한 내용은 +[파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. + +### 파드가 여러 컨테이너를 관리하는 방법 + +파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 +지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 +자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 +리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 +조정할 수 있다. + +예를 들어, 다음 다이어그램에서와 같이 +공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 +별도의 "사이드카" 컨테이너가 있을 수 있다. + +{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}} + +일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다. + +파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는 +두 가지 종류의 공유 ​​리소스를 제공한다. + +## 파드 작업 + +사용자가 쿠버네티스에서 직접 개별 파드를 만드는 경우는 거의 없다. 싱글톤 파드도 마찬가지이다. 이는 +파드가 상대적으로 일시적인, 일회용 엔티티로 설계되었기 때문이다. 파드가 +생성될 때(사용자가 직접 또는 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}가 간접적으로), 새 파드는 +클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행되도록 스케줄된다. +파드는 파드 실행이 완료되거나, 파드 오브젝트가 삭제되거나, +리소스 부족으로 인해 파드가 *축출* 되거나, 노드가 실패할 때까지 해당 노드에 남아있다. + +{{< note >}} +파드에서 컨테이너를 다시 시작하는 것과 파드를 다시 시작하는 것을 혼동해서는 안된다. 파드는 +프로세스가 아니라 컨테이너를 실행하기 위한 환경이다. 파드는 +삭제될 때까지 유지된다. +{{< /note >}} + +파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한 +[DNS 하위 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다. + +### 파드와 컨트롤러 + +워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 ​​있다. 리소스에 대한 컨트롤러는 +파드 장애 시 복제 및 롤아웃과 자동 복구를 +처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을 +인식하고 대체 파드를 생성한다. 스케줄러는 +대체 파드를 정상 노드에 배치한다. + +다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 몇 가지 예시이다. + +* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} +* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} +* {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} + +### 파드 템플릿 + +{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 +_파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드를 관리한다. + +파드템플릿(PodTemplate)은 파드를 생성하기 위한 명세이며, +[디플로이먼트](/docs/concepts/workloads/controllers/deployment/), +[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/) 및 +[데몬셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다. + +워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 `PodTemplate` 을 +사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가 +무엇이든지 원하는 상태의 일부이다. + +아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡의 +매니페스트이다. 해당 파드의 컨테이너는 메시지를 출력한 다음 일시 중지한다. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # 여기서부터 파드 템플릿이다 + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # 여기까지 파드 템플릿이다 +``` + +파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는 +파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신, +수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다. + +예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재 +파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는 +기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드 +리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다. + +노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은 +파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한 +상세 내용은 추상화된다. 이러한 추상화와 관심사 분리(separation of concerns)는 +시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 +확장할 수 있게 한다. + +## 리소스 공유와 통신 + +파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 +지원한다. + +### 파드 스토리지 {#pod-storage} + +파드는 공유 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 +집합을 지정할 수 있다. 파드의 모든 컨테이너는 +공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수 +있다. 또한 볼륨은 내부 컨테이너 중 하나를 다시 +시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용한다. +쿠버네티스가 공유 스토리지를 구현하고 파드에서 사용할 수 있도록 하는 방법에 대한 +자세한 내용은 [스토리지](/ko/docs/concepts/storage/)를 참고한다. + +### 파드 네트워킹 + +각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의 +모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를 +공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한 +컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가 +*파드 외부의* 엔티티와 통신할 때, +공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. +파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, +`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는 +POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 +통신할 수도 있다. 다른 파드의 컨테이너는 +고유한 IP 주소를 가지며 +[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다. +다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 +사용하여 통신할 수 있다. + +파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 +`name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한 +자세한 내용이 있다. + +## 컨테이너에 대한 특권 모드 + +파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. +특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다. + +{{< note >}} +이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다. +{{< /note >}} + +## 정적 파드 + +_정적 파드_ 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}가 +관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접 +관리된다. +대부분의 파드는 컨트롤 플레인(예를 들어, +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}})에 의해 관리되고, 정적 파드의 +경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다). + +정적 파드는 항상 특정 노드의 {{< glossary_tooltip term_id="kubelet" >}} 하나에 바인딩된다. +정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉, +kubelet을 사용하여 개별 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)를 감독한다. + +kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드" term_id="mirror-pod" >}}를 +생성하려고 한다. +즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, +여기에서 제어할 수는 없다는 의미이다. + +## {{% heading "whatsnext" %}} + +* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다. +* [PodPresets](/ko/docs/concepts/workloads/pods/podpreset/)에 대해 알아본다. +* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여 + 다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다. +* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다. +* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다. +* 파드는 쿠버네티스 REST API의 최상위 리소스이다. + [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + 오브젝트 정의는 오브젝트를 상세히 설명한다. +* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](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/). diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 0e46b4bf5e..5f13dddef9 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -12,9 +12,6 @@ weight: 60 또한 클러스터의 업그레이드와 오토스케일링과 같은 클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. - - - ## 자발적 중단과 비자발적 중단 @@ -44,7 +41,7 @@ weight: 60 - 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트 - 파드를 직접 삭제(예: 우연히) -클러스터 관리자의 작업: +클러스터 관리자의 작업은 다음을 포함한다. - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/). - 클러스터의 스케일 축소를 위한 @@ -68,7 +65,7 @@ weight: 60 비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다. -- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. +- 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다. - 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) @@ -86,58 +83,57 @@ weight: 60 클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. -쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을 -실행 할 수 있는 기능을 제공한다. -우리는 이 기능을 *Disruption Budgets* 이라 부른다. - - -## Disruption Budgets의 작동 방식 +## 파드 disruption budgets {{< feature-state for_k8s_version="v1.5" state="beta" >}} -애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다. +쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을 +실행하는 데 도움이 되는 기능을 제공한다. + +애플리케이션 소유자로써, 사용자는 각 애플리케이션에 대해 PodDisruptionBudget(PDB)을 만들 수 있다. PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. -예를 들어 정족수 기반의 애플리케이션이 +예를 들어, 정족수 기반의 애플리케이션이 실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다. 웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 일정 비율 이하로 떨어지지 않도록 보장할 수 있다. 클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 -불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다. -예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다. +불리는 PodDisruptionBudget을 준수하는 도구를 이용해야 한다. -클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다. -해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다. +예를 들어, `kubectl drain` 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수 +있다. `kubectl drain` 을 실행하면, 도구는 사용자가 서비스를 중단하는 노드의 +모든 파드를 축출하려고 한다. `kubectl` 이 사용자를 대신하여 수행하는 축출 요청은 일시적으로 거부될 수 있으며, -도구는 모든 파드가 종료되거나 +도구는 대상 노드의 모든 파드가 종료되거나 설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다. PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다. 예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다. 만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, -Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. +Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적인 중단을 허용한다. 파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다. -파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다. -컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다. +파드의 "의도"하는 수량은 해당 파드를 관리하는 워크로드 리소스의 `.spec.replicas` 를 +기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여 +소유하는 워크로드 리소스를 발견한다. PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만, 버짓이 차감된다. 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. -그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는 -롤링 업데이트시 PDB의 제한을 받지 않는다. -애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. -([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.) +그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는 +롤링 업데이트 시 PDB의 제한을 받지 않는다. 대신, 애플리케이션 업데이트 중 +실패 처리는 특정 워크로드 리소스에 대한 명세에서 구성된다. -파드를 Eviction API로 축출하면 정상적으로 종료된다. -([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.) +Eviction API를 사용하여 파드를 축출하면, +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 +`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.) -## PDB 예시 +## PodDisruptionBudget 예시 {#pdb-example} `node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자. 클러스터에는 여러 애플리케이션을 실행하고 있다. @@ -267,3 +263,6 @@ Pod Disruption Budget을 사용할 필요가 없다. * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 + +* 롤아웃 중에 가용성을 유지하는 단계를 포함하여 + [디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 379266e351..43d54aff46 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,17 +6,61 @@ weight: 30 -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} - -이 페이지는 파드의 라이프사이클을 설명한다. +이 페이지에서는 파드의 라이프사이클을 설명한다. 파드는 정의된 라이프사이클을 따른다. +`Pending` [단계](#파드의-단계)에서 시작해서, 기본 컨테이너 중 적어도 하나 +이상이 OK로 시작하면 `Running` 단계를 통과하고, 그런 다음 파드의 컨테이너가 +실패로 종료되었는지 여부에 따라 `Succeeded` 또는 `Failed` 단계로 이동한다. +파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시 +시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너 +[상태](#컨테이너-상태)와 핸들을 추적한다. +쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다. +파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다. +사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에 +[사용자 정의 준비성 정보](#pod-readiness-gate)를 삽입할 수도 있다. +파드는 파드의 수명 중 한 번만 [스케줄](/ko/docs/concepts/scheduling-eviction/)된다. +파드가 노드에 스케줄(할당)되면, 파드는 중지되거나 [종료](#pod-termination)될 때까지 +해당 노드에서 실행된다. -## 파드의 단계(phase) +## 파드의 수명 + +개별 애플리케이션 컨테이너와 마찬가지로, 파드는 비교적 +임시(계속 이어지는 것이 아닌) 엔티티로 간주된다. 파드가 생성되고, 고유 +ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가 +할당되고, 종료(재시작 정책에 따라) 또는 삭제될 때까지 남아있는 노드에 +스케줄된다. +만약 {{< glossary_tooltip term_id="node" text="노드" >}}가 종료되면, 해당 노드에 스케줄된 파드는 +타임아웃 기간 후에 [삭제되도록 스케줄된다](#pod-garbage-collection). + +파드는 자체적으로 자가 치유되지 않는다. 파드가 +{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 실패하거나, +스케줄 작업 자체가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는 +리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라 +부르는 하이-레벨 추상화를 사용하여 +상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다. + +UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신, +해당 파드는 사용자가 원하는 이름은 같지만, UID가 다른, 거의 동일한 새 파드로 +대체될 수 있다. + +{{< glossary_tooltip term_id="volume" text="볼륨" >}}과 +같은 어떤 것이 파드와 동일한 수명을 갖는다는 것은, +특정 파드(정확한 UID 포함)가 존재하는 한 그것이 존재함을 +의미한다. 어떤 이유로든 해당 파드가 삭제되고, 동일한 대체 파드가 +생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고 +새로 생성된다. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와 +파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.* + +## 파드의 단계 파드의 `status` 필드는 `phase` 필드를 포함하는 @@ -34,189 +78,107 @@ weight: 30 값 | 의미 :-----|:----------- -`Pending` | 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. -`Running` | 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. -`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. -`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. -`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다. +`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다. +`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다. +`Succeeded` | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다. +`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. +`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. -## 파드의 조건(condition) +노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는 +손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다. + +## 컨테이너 상태 + +전체 파드의 [단계](#파드의-단계)뿐 아니라, 쿠버네티스는 파드 내부의 +각 컨테이너 상태를 추적한다. +[컨테이너 라이프사이클 훅(hook)](/docs/concepts/containers/container-lifecycle-hooks/)을 +사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다. + +일단 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가 +노드에 파드를 할당하면, kubelet은 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 +사용하여 해당 파드에 대한 컨테이너 생성을 시작한다. +표시될 수 있는 세 가지 컨테이너 상태는 `Waiting`, `Running` 그리고 `Terminated` 이다. + +파드의 컨테이너 상태를 확인하려면, `kubectl describe pod ` 를 +사용할 수 있다. 출력 결과는 해당 파드 내의 각 컨테이너 상태가 +표시된다. + +각 상태에는 특정한 의미가 있다. + +### `Waiting` {#container-state-waiting} + +만약 컨테이너가 `Running` 또는 `Terminated` 상태가 아니면, `Waiting` 상태이다. +`Waiting` 상태의 컨테이너는 시작을 완료하는 데 필요한 +작업(예를 들어, 컨테이너 이미지 레지스트리에서 컨테이너 이미지 가져오거나, +{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}} 데이터를 적용하는 작업)을 +계속 실행하고 있는 중이다. +`kubectl` 을 사용하여 컨테이너가 `Waiting` 인 파드를 쿼리하면, 컨테이너가 +해당 상태에 있는 이유를 요약하는 Reason 필드도 표시된다. + +### `Running` {#container-state-running} + +`Running` 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. `postStart` 훅이 +구성되어 있었다면, 이미 실행이 완료되었다. `kubectl` 을 +사용하여 컨테이너가 `Running` 인 파드를 쿼리하면, 컨테이너가 `Running` 상태에 진입한 시기에 대한 +정보도 볼 수 있다. + +### `Terminated` {#container-state-terminated} + +`Terminated` 상태의 컨테이너는 실행을 시작한 다음 완료될 때까지 +실행되었거나 어떤 이유로 실패했다. `kubectl` 을 사용하여 컨테이너가 `Terminated` 인 파드를 +쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과 +종료 시간이 표시된다. + +컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에 +실행된다. + +## 컨테이너 재시작 정책 {#restart-policy} + +파드의 `spec` 에는 `restartPolicy` 필드가 있다. 사용 가능한 값은 Always, OnFailure 그리고 +Never이다. 기본값은 Always이다. + +`restartPolicy` 는 파드의 모든 컨테이너에 적용된다. `restartPolicy` 는 +동일한 노드에서 kubelet에 의한 컨테이너 재시작만을 의미한다. 파드의 컨테이너가 +종료된 후, kubelet은 5분으로 제한되는 지수 백오프 지연(10초, 20초, 40초, …)으로 +컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면, +kubelet은 해당 컨테이너의 재시작 백오프 타이머를 +재설정한다. + +## 파드의 조건 파드는 하나의 PodStatus를 가지며, 그것은 파드가 통과했거나 통과하지 못한 조건에 대한 [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. -PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 있다. -* `lastProbeTime` 필드는 -파드의 조건이 마지막으로 조사된 시점의 타임스탬프를 제공한다. +* `PodScheduled`: 파드가 노드에 스케줄되었다. +* `ContainersReady`: 파드의 모든 컨테이너가 준비되었다. +* `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가 + 성공적으로 시작되었다. +* `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드 + 밸런싱 풀에 추가되어야 한다. -* `lastTransitionTime` 필드는 -파드가 마지막으로 한 상태에서 다른 상태로 전환된 시점의 타임스탬프를 제공한다. +필드 이름 | 설명 +:--------------------|:----------- +`type` | 이 파드 조건의 이름이다. +`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 조건이 적용 가능한지 여부를 나타낸다. +`lastProbeTime` | 파드 조건이 마지막으로 프로브된 시간의 타임스탬프이다. +`lastTransitionTime` | 파드가 한 상태에서 다른 상태로 전환된 마지막 시간에 대한 타임스탬프이다. +`reason` | 조건의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다. +`message` | 마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지이다. -* `message` 필드는 -전환에 대한 세부 정보를 표시한, 사람이 읽을 수 있는 메시지이다. - -* `reason` 필드는 마지막으로 발생한 전환의 이유다. 이유는 유일하게, 한 단어로, 카멜 표기법(CamelCase)으로 표기된다. - -* `status` 필드는 `True`", "`False`", 그리고 "`Unknown`"으로 지정될 수 있는 문자열이다. - -* `type` 필드는 다음과 같은 가능한 값들의 문자열이다. - - * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음. - * `Ready`: 파드는 요청들을 수행할 수 있으며 - 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. - * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가 - 성공적으로 시작 완료되었음. - * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임. - - - -## 컨테이너 프로브(probe) - -[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 -컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. -진단을 수행하기 위해서, -kubelet은 컨테이너에 의해서 구현된 -[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. -핸들러에는 다음과 같이 세 가지 타입이 있다. - -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) - 은 컨테이너 내에서 지정된 명령어를 실행한다. - 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. - -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core) - 은 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. - 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. - -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) - 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 - 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 - 진단이 성공한 것으로 간주한다. - -각 probe는 다음 세 가지 결과 중 하나를 가진다. - -* Success: 컨테이너가 진단을 통과함. -* Failure: 컨테이너가 진단에 실패함. -* Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. - -kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 -그에 반응할 수 있다. - -* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 - 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 - [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가 - 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. - -* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. - 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 - 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 - 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 - 지원하지 않는다면, 기본 상태는 `Success`이다. - -* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. - 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 - 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, - 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 - 프로브가 없는 경우, 기본 상태는 `Success`이다. - -### 언제 활성 프로브를 사용해야 하는가? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 -상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 -반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에 -따라서 올바른 대처를 자동적으로 수행할 것이다. - -프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 -지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. - -### 언제 준비성 프로브를 사용해야 하는가? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다. -이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, -스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 -시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다. -만약 컨테이너가 대량의 데이터, 설정 파일들, -또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다. - -만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, -준비성 프로브를 지정하길 바란다. -준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다. - -파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로, -준비성 프로브가 필요하지는 않다는 점을 유념해야한다. 삭제 시에, 파드는 -프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. -파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 -남아있는다. - -### 언제 스타트업 프로브를 사용해야 하는가? - -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다. -이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다. - -활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는, -[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. - -## 파드 및 컨테이너 상태 - -파드 및 컨테이너 상태에 대한 자세한 정보는, -[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 및 -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참조하면 된다. -파드의 상태로서 보고되는 정보는 -현재의 [ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 -의존적이라는 점에 유의하길 바란다. - -## 컨테이너 상태 - -일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다. - -* `Waiting`: 컨테이너의 기본 상태이다. 컨테이너가 Running 이나 Terminated 상태가 아닌 경우, Waiting 상태이다. Waiting 상태의 컨테이너는 이미지를 내려받거나(pull), 시크릿을 적용하는 등의 필요한 오퍼레이션이 수행 중인 상태이다. 이 상태와 더불어서, 더 자세한 정보를 제공하기 위해 상태에 대한 메시지와 이유가 출력된다. - - ```yaml - ... - State: Waiting - Reason: ErrImagePull - ... - ``` - -* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. `postStart` 훅(있는 경우)은 컨테이너가 Running 상태가 되기 전에 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다. - - ```yaml - ... - State: Running - Started: Wed, 30 Jan 2019 16:46:38 +0530 - ... - ``` - -* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. - - ```yaml - ... - State: Terminated - Reason: Completed - Exit Code: 0 - Started: Wed, 30 Jan 2019 11:45:26 +0530 - Finished: Wed, 30 Jan 2019 11:45:26 +0530 - ... - ``` ## 파드의 준비성(readiness) {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} 애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ -와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 -위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. +와 같이 주입할 수 있다. 이를 사용하기 위해, kubelet이 파드의 준비성을 평가하기 +위한 추가적인 조건들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다. 준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 조건을 찾지 못한다면, 그 조건의 상태는 -기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다. +기본 값인 "`False`"가 된다. 여기 예제가 있다. @@ -258,151 +220,225 @@ status: 경우에 **만** 해당 파드가 준비된 것으로 평가된다. * 파드 내의 모든 컨테이너들이 준비 상태이다. -* `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. +* `readinessGates`에 지정된 모든 조건들이 `True` 이다. 파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면, -Kubelet은 파드의 상태를 `ContainerReady`로 설정한다. +kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정한다. -## 재시작 정책 +## 컨테이너 프로브(probe) -PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. -기본 값은 항상(Always)이다. -`restartPolicy`는 파드 내의 모든 컨테이너들에 적용된다. `restartPolicy`는 -같은 노드에 있는 kubelet에 의한 컨테이너들의 재시작에만 관련되어 있다. -kubelet에 의해서 재시작되는 종료된 컨테이너는 -5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며, -10분의 성공적 실행 후에 재설정된다. -[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이, -파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다. +[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 +컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. +진단을 수행하기 위해서, +kubelet은 컨테이너에 의해서 구현된 +[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. +핸들러에는 다음과 같이 세 가지 타입이 있다. +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)은 + 컨테이너 내에서 지정된 명령어를 실행한다. + 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. -## 파드의 일생(lifetime) +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)은 + 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. + 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. -일반적으로, 파드는 사람 혹은 -{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}의 -프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다. -컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서 -`terminated-pod-gc-threshold`에 의해 결정)를 초과할 때, -종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다. -이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다. +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)은 + 지정한 포트 및 경로에서 컨테이너의 IP주소에 + 대한 HTTP `GET` 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 + 진단이 성공한 것으로 간주한다. -파드에는 다음과 같은 다양한 종류의 리소스가 있다. +각 probe는 다음 세 가지 결과 중 하나를 가진다. -- 예를 들어 웹 서버와 같이 종료되지 않을 것으로 예상되는 파드용 - {{< glossary_tooltip term_id="deployment" >}}, {{< glossary_tooltip term_id="replica-set" >}} 또는 - {{< glossary_tooltip term_id="statefulset" >}}을 사용한다. +* `Success`: 컨테이너가 진단을 통과함. +* `Failure`: 컨테이너가 진단에 실패함. +* `Unknown`: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. -- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 - {{< glossary_tooltip term_id="job" >}}을 - 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 - 지정된 경우에 적합하다. +kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 +그에 반응할 수 있다. -- 적합한 노드 당 하나씩 실행해야 하는 파드에는 - {{< glossary_tooltip term_id="daemonset" >}}을 사용한다. +* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 + 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 + [재시작 정책](#restart-policy)의 대상이 된다. 만약 컨테이너가 + 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. -모든 워크로드 리소스에는 파드명세가 포함된다. 사용자가 직접적으로 파드를 생성하는 -것보다 적절한 워크로드 리소스를 생성하고 리소스 컨트롤러가 -사용자를 위한 파드를 생성하도록 하는 것을 권장한다. +* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. + 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 + 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 + 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 + 지원하지 않는다면, 기본 상태는 `Success`이다. -만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 -잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다. +* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 + 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, + 컨테이너는 [재시작 정책](#restart-policy)에 따라 처리된다. 컨테이너에 스타트업 + 프로브가 없는 경우, 기본 상태는 `Success`이다. -## 예제 +활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는, +[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. -### 고급 활성 프로브 예제 +### 언제 활성 프로브를 사용해야 하는가? -활성 프로브는 kubelet에 의해서 실행된다. 따라서 모든 요청은 -kubelet 네트워크 네임스페이스에서 이루어진다. +{{< feature-state for_k8s_version="v1.0" state="stable" >}} -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # "host"가 정의되지 않은 경우, "PodIP" 가 사용될 것이다. - # host: my-host - # "scheme"이 정의되지 않은 경우, "HTTP" 스키마가 사용될 것이다. "HTTP"와 "HTTPS"만 허용된다. - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` +만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 +상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 +반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에 +따라서 올바른 대처를 자동적으로 수행할 것이다. -### 상태 예제 +프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 +지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. - * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 성공으로 종료됐다. - * 완료 이벤트를 기록한다. - * 만약 `restartPolicy`가 : - * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 실패 시(OnFailure)이면: 파드의 `phase`는 Succeeded가 된다. - * 절대 안 함(Never)이면: 파드의 `phase`는 Succeeded가 된다. +### 언제 준비성 프로브를 사용해야 하는가? - * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 실패로 종료됐다. - * 실패 이벤트를 기록한다. - * 만약 `restartPolicy`가 : - * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다. +{{< feature-state for_k8s_version="v1.0" state="stable" >}} - * 파드가 동작 중이고 두 개의 컨테이너를 가지고 있다. 컨테이너 1이 실패로 종료됐다. - * 실패 이벤트를 기록한다. - * 만약 `restartPolicy`가 : - * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 절대 안 함(Never)이면: 컨테이너는 재시작되지 않고, 파드의 `phase`는 Running으로 유지된다. - * 만약 컨테이너 1이 동작 중이 아니고, 컨테이너 2가 종료됐다면 : - * 실패 이벤트를 기록한다. - * 만약 `restartPolicy`가 : - * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다. +프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, +준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 +보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 +트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 +트래픽을 받는다는 뜻이다. +만약 컨테이너가 대량의 데이터, 설정 파일들, +또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다. - * 파드는 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너의 메모리가 부족하다. - * 컨테이너는 실패로 종료된다. - * 메모리 부족(OOM) 이벤트를 기록한다. - * 만약 `restartPolicy`가 : - * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. - * 절대 안 함(Never)이면: 로그 실패 이벤트가 발생되고, 파드의 `phase`는 Failed가 된다. +만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, +준비성 프로브를 지정하길 바란다. +준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다. - * 파드 동작 중에, 디스크가 죽었다. - * 모든 컨테이너들을 죽인다. - * 적절한 이벤트를 기록한다. - * 파드의 `phase`는 Failed가 된다. - * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. +{{< note >}} +파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로, +준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는 +프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. +파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 +남아 있다. +{{< /note >}} - * 파드 동작 중에, 파드가 있는 노드가 세그먼티드 아웃되었다. - * 노드 컨트롤러가 타임아웃을 기다린다. - * 노드 컨트롤러가 파드의 `phase`를 Failed로 설정한다. - * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. +### 언제 스타트업 프로브를 사용해야 하는가? +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는 +파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때 +프로브를 위한 별도의 구성을 설정하여, 활성 간격보다 +긴 시간을 허용할 수 있다. + +컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` +이후에 기동된다면, 스타트업 프로브가 +활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다. +`periodSeconds`의 기본값은 30s 이다. 이 때 컨테이너가 활성화 프로브의 +기본값 변경 없이 기동되도록 하려면, `failureThreshold` 를 충분히 높게 설정해주어야 +한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다. + +## 파드의 종료 {#pod-termination} + +파드는 클러스터의 노드에서 실행되는 프로세스를 나타내므로, 해당 프로세스가 +더 이상 필요하지 않을 때 정상적으로 종료되도록 하는 것이 중요하다(`KILL` +시그널로 갑자기 중지되고 정리할 기회가 없는 것 보다). + +디자인 목표는 삭제를 요청하고 프로세스가 종료되는 시기를 알 수 +있을 뿐만 아니라, 삭제가 결국 완료되도록 하는 것이다. +사용자가 파드의 삭제를 요청하면, 클러스터는 파드가 강제로 종료되기 전에 +의도한 유예 기간을 기록하고 추적한다. 강제 종료 추적이 +적용되면, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 정상 +종료를 시도한다. + +일반적으로, 컨테이너 런타임은 TERM 시그널을 각 컨테이너의 기본 프로세스로 +전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로 +전송되고, 그런 다음 파드는 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가 +종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는 +전체 원래 유예 기간을 포함하여 처음부터 다시 시도한다. + +플로우의 예는 다음과 같다. + +1. 이 `kubectl` 도구를 사용하여 기본 유예 기간(30초)으로 특정 파드를 수동으로 + 삭제한다. +1. API 서버의 파드는 유예 기간과 함께 파드가 "dead"로 간주되는 + 시간으로 업데이트된다. + `kubectl describe` 를 사용하여 삭제하려는 파드를 확인하면, 해당 파드가 "Terminating"으로 + 표시된다. + 파드가 실행 중인 노드에서, kubelet이 파드가 종료된 것(terminating)으로 표시되었음을 + 확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료 + 프로세스를 시작한다. + 1. 파드의 컨테이너 중 하나가 `preStop` + [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은 + 컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이 + 계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을 + 요청한다. + {{< note >}} + `preStop` 훅을 완료하는 데 기본 유예 기간이 허용하는 것보다 오랜 시간이 필요한 경우, + 이에 맞게 `terminationGracePeriodSeconds` 를 수정해야 한다. + {{< /note >}} + 1. kubelet은 컨테이너 런타임을 트리거하여 각 컨테이너 내부의 프로세스 1에 TERM 시그널을 + 보낸다. + {{< note >}} + 파드의 컨테이너는 서로 다른 시간에 임의의 순서로 TERM 시그널을 + 수신한다. 종료 순서가 중요한 경우, `preStop` 훅을 사용하여 동기화하는 것이 좋다. + {{< /note >}} +1. kubelet이 정상 종료를 시작하는 동시에, 컨트롤 플레인은 + 구성된 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 있는 + {{< glossary_tooltip term_id="service" text="서비스" >}}를 나타내는 + 엔드포인트(Endpoint)(그리고, 활성화된 경우, 엔드포인트슬라이스(EndpointSlice)) 오브젝트에서 종료된 파드를 제거한다. + {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}과 기타 워크로드 리소스는 + 더 이상 종료된 파드를 유효한 서비스 내 복제본으로 취급하지 않는다. 로드 밸런서(서비스 프록시와 같은)가 + 종료 유예 기간이 _시작되는_ 즉시 엔드포인트 목록에서 파드를 제거하므로 느리게 종료되는 + 파드는 트래픽을 계속 제공할 수 없다. +1. 유예 기간이 만료되면, kubelet은 강제 종료를 트리거한다. 컨테이너 런타임은 + `SIGKILL` 을 파드의 모든 컨테이너에서 여전히 실행 중인 모든 프로세스로 전송한다. + kubelet은 해당 컨테이너 런타임이 하나를 사용하는 경우 숨겨진 `pause` 컨테이너도 정리한다. +1. kubelet은 유예 기간을 0(즉시 삭제)으로 설정하여, API 서버에서 파드 오브젝트의 + 강제 삭제를 트리거한다. +1. API 서버가 파드의 API 오브젝트를 삭제하면, 더 이상 클라이언트에서 볼 수 없다. + +### 강제 파드 종료 {#pod-termination-forced} + +{{< caution >}} +강제 삭제는 일부 워크로드와 해당 파드에 대해서 잠재적으로 중단될 수 있다. +{{< /caution >}} + +기본적으로, 모든 삭제는 30초 이내에는 정상적으로 수행된다. `kubectl delete` 명령은 +기본값을 재정의하고 사용자의 고유한 값을 지정할 수 있는 `--grace-period=` 옵션을 +지원한다. + +유예 기간을 `0` 로 강제로 즉시 설정하면 API 서버에서 파드가 +삭제된다. 파드가 노드에서 계속 실행 중인 경우, 강제 삭제는 kubelet을 트리거하여 +즉시 정리를 시작한다. + +{{< note >}} +강제 삭제를 수행하려면 `--grace-period=0` 와 함께 추가 플래그 `--force` 를 지정해야 한다. +{{< /note >}} + +강제 삭제가 수행되면, API 서버는 실행 중인 노드에서 +파드가 종료되었다는 kubelet의 확인을 기다리지 않는다. +API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파드를 생성할 수 +있다. 노드에서 즉시 종료되도록 설정된 파드는 강제 종료되기 전에 +작은 유예 기간이 계속 제공된다. + +스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우, +[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 +태스크 문서를 참고한다. + +### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection} + +실패한 파드의 경우, API 오브젝트는 사람이나 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 프로세스가 +명시적으로 파드를 제거할 때까지 클러스터의 API에 남아 있다. + +컨트롤 플레인은 파드 수가 구성된 임계값(kube-controller-manager에서 +`terminated-pod-gc-threshold` 에 의해 결정됨)을 초과할 때 종료된 파드(`Succeeded` 또는 +`Failed` 단계 포함)를 정리한다. +이렇게 하면 시간이 지남에 따라 파드가 생성되고 종료될 때 리소스 유출이 방지된다. ## {{% heading "whatsnext" %}} +* [컨테이너 라이프사이클 이벤트에 핸들러를 연결](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)하는 + 핸즈온 연습을 해보자. -* Hands-on 경험하기 - [컨테이너 라이프사이클 이벤트에 핸들러 부착하기](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). - -* Hands-on 경험하기 - [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). - -* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기. - +* [활성, 준비성 및 스타트업 프로브 설정](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)하는 + 핸즈온 연습을 해보자. +* [컨테이너 라이프사이클 훅](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자. +* API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +그리고 +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md deleted file mode 100644 index bf52e77c2a..0000000000 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: 파드(Pod) 개요 -content_type: concept -weight: 10 -card: - name: concepts - weight: 60 ---- - - -이 페이지는 쿠버네티스 객체 모델 중 가장 작은 배포 가능한 객체인 `파드` 에 대한 개요를 제공한다. - - - - -## 파드에 대해 이해하기 - -*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" text="클러스터" >}} 에서의 Running 프로세스를 나타낸다. - -파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 정체성(IP 주소) 및 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 {{< glossary_tooltip text="컨테이너" term_id="container" >}}로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미한다. - -[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다. - - -쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다. - -* **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. -* **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. - -각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. -복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. -쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. - -## 어떻게 파드가 다중 컨테이너를 관리하는가 - -파드는 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. 파드 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제,어떻게 조절하는지를 공유할 수 있다. - -단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다. - -{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} - -몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다. - -파드는 같은 파드 안에 속한 컨테이너에게 두 가지 공유 리소스를 제공한다. *네트워킹* 과 *저장소*. - -#### 네트워킹 - -각각의 파드는 각 주소 패밀리의 고유한 IP 주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost` 를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유해야 한다(예를 들어 포트 등). - -#### 저장소 - -파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다. - -## 파드 작업 - -직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들 일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}}에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 오브젝트가 삭제되거나, 파드가 리소스의 부족으로 인해 *축출되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있다. - -{{< note >}} -파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 프로세스가 아니라, 컨테이너를 실행하는 환경이다. 파드는 삭제될 때까지 유지된다. -{{< /note >}} - -파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 축출되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용할 수 있지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서는 훨씬 더 보편적이다. - -### 파드와 컨트롤러 - -워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. - -다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다. - -* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} -* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} -* {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} - - -## 파드 템플릿 - -{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 -사용자를 대신해서 이러한 파드를 관리한다. - -파드템플릿은 파드를 생성하기 위한 명세이며 -[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/), -[잡](/ko/docs/concepts/jobs/run-to-completion-finite-workloads/) 그리고 -[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함되어 있다. - -워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 파드템플릿을 사용해서 실제 파드를 만든다. 파드템플릿은 앱을 실행하는 데 사용되는 모든 워크로드 리소스의 의도하는 상태의 일부이다. - -아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡에 대한 매니페스트이다. 파드의 컨테이너가 메시지를 출력한 후 일시 중지하게 된다. - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: hello -spec: - template: - # 이것이 파드 템플릿이다. - spec: - containers: - - name: hello - image: busybox - command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] - restartPolicy: OnFailure - # 여기가 파드 템플릿의 끝이다. -``` - -파드 템플릿을 수정하거나 새 파드 템플릿으로 전환해도 이미 존재하는 파드에는 영향을 미치지 않는다. 파드는 템플릿 업데이트를 직접 수신하지 않지만, 대신에 수정된 파드 템플릿과 일치하는 새 파드가 생성된다. - -예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 현재 파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트되면, 컨트롤러는 업데이트된 템플릿을 기반으로 기존 파드를 제거하고 새 파드를 생성한다. 각 워크로드 컨트롤러는 파드 템플릿의 변경사항을 처리하기 위해 자체 규칙을 구현한다. - -노드에서 "kubelet"이 파드 템플릿과 업데이트에 관련된 세부 정보를 직접 관찰하거나 관리하지 않으며, 이러한 세부 정보는 추상화되지 않는다. 이러한 추상화와 분리는 시스템 시맨틱을 단순화하며, 기존 코드를 변경하지 않고 클러스터의 동작을 확장할 수 있도록 한다. - - - -## {{% heading "whatsnext" %}} - -* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. -* [분산 시스템 툴킷: 복합 컨테이너의 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 공통 레이아웃에 대해 설명한다. -* 파드의 동작에 대해 더 알아보자. - * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) - * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index d92b18a1bf..8fe6e45134 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -1,7 +1,7 @@ --- title: 파드 토폴로지 분배 제약 조건 content_type: concept -weight: 50 +weight: 40 --- diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index e3464ff5cf..0000000000 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -title: 파드 -content_type: concept -weight: 20 ---- - - - -_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 -배포 가능한 최소 컴퓨팅 단위이다. - - - - - - -## 파드는 무엇인가? - -_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) -{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다. -이 그룹은 스토리지/네트워크를 공유하고, -해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. -파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다. -파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다. -이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다. -컨테이너 이전의 세상에서 같은 물리적 또는 가상의 머신에서 실행되는 것은 -같은 논리적 호스트에서 실행되고 있는 것을 의미한다. - -쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만, -도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다. - -파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 -도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. -파드의 컨텍스트 내에서 개별 응용 프로그램은 -추가적으로 하위 격리가 적용된다. - -파드 안의 컨테이너들은 IP주소와 포트 공간을 공유하고, -서로를 `localhost` 를 통해 찾을 수 있다. -그들은 또한 SystemV 세마포어나, POSIX 공유 메모리와 같은 표준 프로세스 간 통신 방식으로 -서로 통신할 수 있다. -다른 파드의 컨테이너에는 고유한 IP 주소가 있고, -[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이는 IPC에 의해서 통신 할 수 없다. -컨테이너는 주로 서로의 IP 주소를 통해 소통한다. - -또한 파드 안의 애플리케이션은 파드의 일부로 정의되어, -각각의 애플리케이션의 파일시스템에 마운트 할 수 있도록 만들어진 -공유 볼륨에 엑세스 할 수 있다. - -[도커](https://www.docker.com/)의 구조 관점에서 보면 -파드는 공유 네임스페이스와 공유 [볼륨](/ko/docs/concepts/storage/volumes/)을 가진 -도커 컨테이너 그룹으로 모델링 된다. - -개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다. -[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, -파드가 만들어지고 고유한 ID(UID)가 할당되고, -재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. -노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다. -해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. -대신, 동일한 파드로, -원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다. -더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. - -볼륨과 같이 파드와 동일한 수명이 있다고 하면, -UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다. -어떤 이유로든 해당 파드가 삭제 된 경우, -동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다. - -{{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}} - -*파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는 -웹 서버를 포함하는 멀티 컨테이너 파드.* - -## 파드의 의의 - -### 관리 - -파드는 응집력 있는 서비스 단위를 형성하는 여러 개의 협력 프로세스를 모델로 한다. -파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써 -애플리케이션 배포 및 관리를 단순화한다. -파드는 전개 단위, 수평 확장 및 복제를 한다. -공동 스케줄링, -공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는 -파드의 컨테이너에 대해 자동으로 처리된다. - -### 리소스 공유 및 통신 - -파드는 그 구성 요소 간에 데이터 공유 및 통신이 가능하다. - -파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로 -서로를 찾고 통신하는데 `localhost`를 사용할 수 있다. -이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다. -각 파드에는 다른 물리적 컴퓨터 및 파드들과 -네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. - -호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다. -더 자세한 내용은 -[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다. - -파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다. -볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고, -파드 안의 애플리케이션들끼리 데이터를 공유할 수 있게 해준다. - -## 파드의 사용 - -파드는 수직으로 통합 된 애플리케이션 스택(예 : LAMP)을 호스팅하는 데 사용할 수 있다. -하지만, 주요 동기는 공동 배치 및 공동 관리되는 헬퍼(helper) 프로그램을 지원하는 것이다. -예를 들면, - -* 컨텐츠 관리 시스템, 파일과 데이터 로더, 로컬 캐시 관리 등. -* 로그와 백업 체크포인트, 압축, 로테이션, 스냅샷 등. -* 데이터 변동 감시자, 로그 추적자, 로깅 및 모니터링 어댑터, 이벤트 관리 등. -* 프록시, 브릿지, 어댑터 -* 컨트롤러, 매니저, 설정, 업데이트 - -일반적으로 하나의 파드는 -동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다. - -더 자세한 설명을 보려면 -[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 -참조한다. - -## 고려된 대안 - -_싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_ - -1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면, - 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 - 제공할 수 있다. - 이 기능들은 사용자에게 편의를 제공한다. -1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리, - 재빌드, 재배포될 수 있다. - 언젠가는 쿠버네티스에서 개별 컨테이너의 실시간 업데이트도 할 수 있을 것이다. -1. 사용의 편의성. 사용자는 자신의 프로세스 매니저를 따로 실행 할 필요가 없고, - 시그널이나 종료 코드(exit-code) 전파 등에 대해 걱정할 필요가 없다. -1. 효율성. 인프라측에서 많은 책임을 가지고 있으므로, - 컨테이너는 더 가벼워 질 수 있다. - -_컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하지 않는 이유는 무엇인가?_ - -이와 같은 접근은 공동위치를 제공하지만, -리소스 공유, IPC, 보장된 생애 공유, 관리의 단순화와 같은 -파드가 가진 대부분의 장점을 제공하지 못한다. - -## 파드의 내구성 (또는 결핍) - -파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. - -일반적으로 사용자는 파드를 직접 만들 필요가 없다. -싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. -컨트롤러는 클러스터 범위에서 -복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다. -[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은 -컨트롤러는 상태를 저장하는 파드에도 -위와 같은 기능 제공을 할 수 있다. - -사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. - -파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: - -* 스케줄러 및 컨트롤러 연결 가능 -* "프록시" 없이 컨트롤러 API를 통한 파드-레벨 수준의 동작 지원 -* 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리 -* 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러 -* 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — Kubelet은 효과적인 "파드 컨트롤러" 이다. -* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션. - -## 파드의 종료 - -파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다. - -흐름 예시: - -1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초) -1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다. -1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다. -1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다. - 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다. - 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다. -1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. -1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다. -1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다. - -기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). -kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다. - -### 파드 강제 삭제 - -파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. - -강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다. - -## 파드 컨테이너의 특권(Privileged) 모드 - -파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. - -{{< note >}} -이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다. -{{< /note >}} - -## API 오브젝트 - -파드는 쿠버네티스 REST API에서 최상위 리소스이다. -API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: -[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). -파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 9793dbc52e..6fad15ece7 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -1,6 +1,4 @@ --- - - title: 파드 프리셋 content_type: concept weight: 50 @@ -32,20 +30,20 @@ weight: 50 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. -1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. - 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다. - minikube에서는 클러스터가 시작할 때 - `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` - 플래그를 추가한다. -1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 - API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다. - minikube에서는 클러스터가 시작할 때 +1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. + 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다. + minikube에서는 클러스터가 시작할 때 + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` + 플래그를 추가한다. +1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 + API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다. + minikube에서는 클러스터가 시작할 때 - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` - 플래그를 추가한다. + 플래그를 추가한다. ## 어떻게 동작하는가 @@ -64,31 +62,28 @@ weight: 50 수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다. `podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`. -각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의 -파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을 -때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의 +각 파드는 0개 이상의 파드프리셋에 일치될 수 있고, 각 파드프리셋은 0개 이상의 +파드에 적용될 수 있다. 하나의 파드프리셋이 한 개 이상의 파드에 적용되었을 +때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `env`, `envFrom`, `volumeMounts`의 변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을 -수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다. +수정한다. `volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다. {{< note >}} 파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다. - `.spec.containers` 필드 -- `initContainers` 필드(쿠버네티스 버전 1.14.0 이후에서 필요) +- `.spec.initContainers` 필드 {{< /note >}} ### 특정 파드의 파드 프리셋 비활성화하기 어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가 -있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 +있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드의 `.spec` 에 추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`. ## {{% heading "whatsnext" %}} - [파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다. 배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다. - - diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 714ae70f36..d5f424cdc7 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -53,8 +53,8 @@ card: - [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. -- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 - 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. +- [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을 + 확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index f66c7f952b..ef271ca31c 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -106,7 +106,7 @@ PR 소유자에게 조언하는데 활용된다. - 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. - SIG Docs 승인자들만이 코멘트에 `/approve` 를 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 - [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과 + [PR Wrangler](/ko/docs/contribute/participate/pr-wranglers/) 또는 [SIG Docs 의장](#sig-docs-의장)과 같은 특정 역할도 수행한다. diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index 4581400ea3..d614905f0a 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -36,17 +36,30 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. 이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다. 이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다. -- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): +- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen): CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고 CLA에 서명한 후 PR을 열 수 있음을 알린다. **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** -- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): +- [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm): 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. -- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): +- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. -- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) -- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) +- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. + +### 랭글러를 위한 유용한 Prow 명령어 + +``` +# 한글 레이블 추가 +/language ko + +# 둘 이상의 커밋인 경우 PR에 스쿼시 레이블 추가 +/label tide/merge-method-squash + +# Prow를 통해 PR 제목 변경(예: 진행 중인 작업(work-in-progress) [WIP] 또는 PR의 더 상세한 내용) +/retitle [WIP] +``` ### 풀 리퀘스트를 종료하는 시기 diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md index 565361ea7b..158e24c0af 100755 --- a/content/ko/docs/reference/glossary/pod.md +++ b/content/ko/docs/reference/glossary/pod.md @@ -2,18 +2,17 @@ title: 파드(Pod) id: pod date: 2018-04-12 -full_link: /ko/docs/concepts/workloads/pods/pod-overview/ +full_link: /ko/docs/concepts/workloads/pods/ short_description: > 파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다. -aka: +aka: tags: - core-object - fundamental --- 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 집합을 나타낸다. -<!--more--> +<!--more--> 파드는 일반적으로 하나의 기본 컨테이너를 실행하기 위해서 구성된다. 또한 파드는 로깅과 같이 보완적인 기능을 추가하기 위한 사이드카 컨테이너를 선택적으로 실행할 수 있다. 파드는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 의해서 관리된다. - diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index d961283b99..0ac842ccc6 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -28,7 +28,7 @@ API 오브젝트로 취급되고, ## API 버전 규칙 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, -쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 +쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. 아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다. @@ -76,7 +76,7 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. 현재 다음과 같은 다양한 API 그룹이 사용되고 있다: -* *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다. +* *핵심* (또는 *레거시* 라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다. * 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다. @@ -101,11 +101,3 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. 그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 `--runtime-config` 변경을 반영해야 한다. {{< /note >}} - -## extensions/v1beta1 그룹 내 특정 리소스 활성화 하기 - -데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크정책, 파드보안정책 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다. -예시: 디플로이먼트와 데몬셋의 활성화 설정은 -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다. - -{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index d29c8f49c2..39efd52b80 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -17,7 +17,7 @@ weight: 20 클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다. -보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다. +보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다. 하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다. @@ -77,7 +77,7 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 ### 애드온 자원 -[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](http://pr.k8s.io/10653/files)과 [#10778](http://pr.k8s.io/10778/files) 참고). +[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고). 예시: @@ -91,34 +91,32 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 memory: 200Mi ``` -힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](http://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](http://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다. +힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다. 많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라. * 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다). - * [InfluxDB와 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, 사이드카](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) + * [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) + * [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) + * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) * 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자): - * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) + * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) * 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다). - * [ElasticSearch 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [GCP 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) + * [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) + * [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) -힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](http://issue.k8s.io/16185)과 -[#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, +힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과 +[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자. -애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라. - -[미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다. -이런 기능들에 대한 PR은 언제든 환영한다. +애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 +[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라. ### 시작 시 사소한 노드 오류 허용 -다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고 +다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고 `kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다. 현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ), -`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다. +`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다. 이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다. 실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다. diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 2ccd3873a0..0693169e5d 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -74,7 +74,7 @@ federation support). a single master node by default. While services are highly available and can tolerate the loss of a zone, the control plane is located in a single zone. Users that want a highly available control -plane should follow the [high availability](/docs/admin/high-availability) instructions. +plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions. ### Volume limitations The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드). diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 16ea2ad587..18e4811457 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -509,6 +509,4 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit ## 커뮤니티 -컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 #minikube 채널(초청받으려면 [여기](http://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자. - - +컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 `#minikube` 채널(초청받으려면 [여기](https://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자. diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 644ca5dae4..0df78ff580 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -140,7 +140,7 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone `example.com`하위에는 그렇지 않을 수 있다). `dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자. -보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 +보통 사용자는 [일반적인 방법](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나 `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다. 그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, diff --git a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md index 7565152bf0..a7351040e6 100644 --- a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -45,13 +45,14 @@ weight: 60 kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` 앞의 명령은 - [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) + {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 오브젝트와 연관된 - [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + {{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}} 오브젝트를 생성한다. 레플리카셋은 두 개의 - [파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고, + {{< glossary_tooltip text="파드" term_id="pod" >}}를 갖고, 각각은 Hello World 애플리케이션을 실행한다. + 1. 디플로이먼트에 대한 정보를 보여준다. ```shell kubectl get deployments hello-world @@ -155,4 +156,3 @@ weight: 60 [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아본다. - diff --git a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index dfd9923113..2d1b723e27 100644 --- a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -4,7 +4,7 @@ content_type: task --- <!-- overview --> -이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을 +이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을 변경하는 방법을 보여준다. @@ -19,14 +19,14 @@ content_type: task ## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가? -`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한 -다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우 -기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면, +퍼시스턴트볼륨은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한 +다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 퍼시스턴트볼륨의 경우 +기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면, 동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다. 볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다. 이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다. -"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는 -`PersistentVolume` 은 삭제되지 않는다. +"Retain" 정책에서, 사용자가 퍼시스턴트볼륨클레임을 삭제할 경우 해당하는 +퍼시스턴트볼륨은 삭제되지 않는다. 대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다. ## 퍼시스턴트볼륨 반환 정책 변경하기 @@ -44,7 +44,7 @@ content_type: task pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s - 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록 + 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록 각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다. 1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다. @@ -77,8 +77,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\" pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s - 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을 - 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우, + 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을 + 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우, 볼륨은 자동으로 삭제 되지 않는다. @@ -93,5 +93,3 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\" * [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기. - - diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 2cf5a8b6e5..fef1abead5 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow ### 윈도우 워커 노드 조인(joining) {{< note >}} `Containers` 기능을 설치하고 도커를 설치해야 한다. -[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다. +[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다. {{< /note >}} {{< note >}} @@ -181,5 +181,3 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드 - [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) - - diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 8eb1c0a68f..41e1f6f7b0 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -14,7 +14,7 @@ content_template: task 직접 관리된다. 컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, kubelet 이 각각의 스태틱 파드를 감시한다. -(만약 충돌이 날 경우 다시 구동한다.) +(만약 실패할 경우 다시 구동한다.) 스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다. diff --git a/content/ko/docs/tasks/extend-kubernetes/_index.md b/content/ko/docs/tasks/extend-kubernetes/_index.md new file mode 100644 index 0000000000..f6394b6b60 --- /dev/null +++ b/content/ko/docs/tasks/extend-kubernetes/_index.md @@ -0,0 +1,5 @@ +--- +title: "쿠버네티스 확장" +description: 쿠버네티스 클러스터를 작업 환경의 요구에 맞게 조정하는 고급 과정을 이해한다. +weight: 90 +--- diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md new file mode 100644 index 0000000000..69dd891509 --- /dev/null +++ b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -0,0 +1,53 @@ +--- +title: 확장 API 서버 설정 +content_type: task +weight: 15 +--- + +<!-- overview --> + +애그리게이션 레이어(aggregation layer)와 작동하도록 확장 API 서버를 설정하면 쿠버네티스 API 서버를 쿠버네티스의 핵심 API의 일부가 아닌 추가 API로 확장할 수 있다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* [애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화해야 한다. + + + +<!-- steps --> + +## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정 + +다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다. + +또는, [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md)와 같은 기존의 타사 솔루션을 사용하여 스켈레톤(skeleton)을 생성하고 다음 단계를 모두 자동화해야 한다. + +1. API서비스(APIService) API가 활성화되어 있는지 확인한다(`--runtime-config` 확인). 클러스터에서 일부러 해제하지 않았다면, 기본적으로 활성화되어 있어야 한다. +1. API서비스 오브젝트를 추가하거나 클러스터 관리자가 작성하도록 RBAC 규칙을 작성해야 할 수도 있다. (API 확장은 전체 클러스터에 영향을 주기 때문에, 운영 중인 클러스터에서 API 확장에 대한 테스트/개발/디버깅을 수행하지 않는 것이 좋다.) +1. 확장 API 서비스를 실행하려는 쿠버네티스 네임스페이스를 생성한다. +1. HTTPS를 위해 확장 API 서버가 사용하는 서버 인증서에 서명하는 데 사용할 CA 인증서를 생성하거나 가져온다. +1. HTTPS를 위해 API 서버가 사용할 서버 인증서/키를 생성한다. 이 인증서는 위의 CA 인증서에 의해 서명해야 한다. 또한 Kube DNS 이름의 CN이 있어야 한다. 이것은 쿠버네티스 서비스에서 파생되었으며 `<service name>.<service name namespace>.svc` 형식이다. +1. 네임스페이스에 서버 인증서/키를 사용하여 쿠버네티스 시크릿을 생성한다. +1. 확장 API 서버에 대한 쿠버네티스 디플로이먼트를 생성하고 시크릿을 볼륨으로 로드하는지 확인한다. 확장 API 서버의 작동하는(working) 이미지에 대한 참조를 포함해야 한다. 디플로이먼트는 네임스페이스에도 있어야 한다. +1. 확장 API 서버가 해당 볼륨에서 해당 인증서를 로드하고 HTTPS 핸드셰이크에 사용되는지 확인한다. +1. 네임스페이스에서 쿠버네티스 서비스 어카운트를 생성한다. +1. 리소스에 허용하려는 작업에 대한 쿠버네티스 클러스터 롤(role)을 생성한다. +1. 네임스페이스의 서비스 어카운트에서 방금 만든 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 생성한다. +1. 네임스페이스의 서비스 어카운트에서 `system:auth-delegator` 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 만들어 인증 결정을 쿠버네티스 핵심 API 서버에 위임한다. +1. 네임스페이스의 서비스 어카운트에서 `extension-apiserver-authentication-reader` 롤로 쿠버네티스 롤 바인딩을 생성한다. 이를 통해 확장 API 서버가 `extension-apiserver-authentication` 컨피그맵(configmap)에 접근할 수 있다. +1. 쿠버네티스 API 서비스를 생성한다. 위의 CA 인증서는 base64로 인코딩되어, 새로운 라인이 제거되고 API 서비스에서 spec.caBundle로 사용되어야 한다. 이것은 namespaced가 아니어야 한다. [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)를 사용하는 경우, base64 인코딩이 수행되므로 PEM 인코딩된 CA 번들만 통과한다. +1. kubectl을 사용하여 리소스를 얻는다. kubectl을 실행하면, "No resources found."가 반환된다. 이 메시지는 +모든 것이 작동됐지만 현재 해당 리소스 유형의 오브젝트가 생성되지 않았음을 나타낸다. + + +## {{% heading "whatsnext" %}} + + +* [API 애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화하는 단계를 수행한다. +* 높은 수준의 개요에 대해서는, [애그리게이션 레이어로 쿠버네티스 API 확장하기](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 참고한다. +* [커스텀 리소스 데피니션을 사용하여 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 알아본다. diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index 4c50079dc3..a2c43f3321 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -52,7 +52,7 @@ kubectl delete pods -l app=myapp ### 퍼시스턴트볼륨(PersistentVolume) -스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. +스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드가 종료된 후 PVC를 삭제하면 스토리지 클래스와 반환 정책에 따라 백업 퍼시스턴트볼륨 삭제가 트리거될 수 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. {{< note >}} PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index ee5db9d3f2..b42f8952b8 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -42,7 +42,7 @@ Dockerfile은 다음과 같다. ``` FROM php:5-apache -ADD index.php /var/www/html/index.php +COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` @@ -481,5 +481,3 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml ``` horizontalpodautoscaler.autoscaling/php-apache created ``` - - diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index bcfcd12e4e..8f45c8ddc2 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -2,5 +2,40 @@ title: "도구 설치" description: 컴퓨터에서 쿠버네티스 도구를 설정한다. weight: 10 +no_list: true --- +## kubectl + +쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을 +실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 +관리하고, 로그를 볼 수 있다. + +클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는 +[kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다. + +`kubectl` 레퍼런스 문서를 읽어볼 수도 있다. + +## Minikube + +[Minikube](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 +도구이다. Minikube는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 +단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을 +수행할 수 있다. + +공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/) +가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면 +[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다. + +Minikube가 작동하면, 이를 사용하여 +[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다. + +## kind + +Minikube와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 +쿠버네티스를 실행할 수 있다. Minikuke와 달리, kind는 단일 컨테이너 런타임에서만 작동한다. +kind는 [도커](https://docs.docker.com/get-docker/)를 설치하고 +구성해야 한다. + +[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 kind를 시작하고 실행하기 위해 +수행해야 하는 작업을 보여준다. diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index e4c8011614..baf003f595 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -26,7 +26,7 @@ card: 1. 다음 명령으로 최신 릴리스를 다운로드한다. ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" ``` 특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 9d71638252..35b4365eb2 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -59,13 +59,13 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. minikube dashboard ``` -3. Katacoda 환경에서는: 터미널 패널의 상단에서 플러스를 클릭하고, 이어서 **Select port to view on Host 1**를 클릭 +3. Katacoda 환경에서는: 터미널 패널의 상단에서 플러스를 클릭하고, 이어서 **Select port to view on Host 1** 을 클릭 -4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port**을 클릭. +4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭. ## 디플로이먼트 만들기 -쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/pod/)는 관리와 +쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/)는 관리와 네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다. 이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스 [*디플로이먼트*](/ko/docs/concepts/workloads/controllers/deployment/)는 파드의 @@ -97,7 +97,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl get pods ``` - + 다음과 유사하게 출력된다. ``` @@ -282,5 +282,3 @@ minikube delete * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. * [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. - - diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 34a69387dc..e2b8098b9e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20 <div class="row"> <div class="col-md-12"> <p> - 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. <a href="/ko/docs/concepts/workloads/pods/pod-overview/#파드에-대해-이해하기">파드에 대해 더 자세히 알아본다</a>. + 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. <a href="/ko/docs/concepts/workloads/pods/">파드에 대해 더 자세히 알아본다</a>. </p> </div> </div> diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 6726fdd6e0..ebc880dbdd 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10 <div class="col-md-8"> <h3>쿠버네티스 서비스들에 대한 개요</h3> - <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p> + <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p> <p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/ko/docs/concepts/configuration/overview/#일반적인-구성-팁">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p> diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index ae9e5abf03..382f096375 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -177,7 +177,7 @@ service/nodeport exposed ```shell NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` 클라우드 공급자 상에서 실행한다면, @@ -206,17 +206,19 @@ client_address=10.240.0.3 시각적으로 -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[Node 2]; + node2-->client; + node2-. SNAT .->node1[Node 1]; + node1-. SNAT .->node2; + node1-->endpoint(Endpoint); + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{</ mermaid >}} 이를 피하기 위해 쿠버네티스는 @@ -261,17 +263,18 @@ client_address=104.132.1.79 시각적으로 -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[Node 1]; + client(client) --x node2[Node 2]; + node1 --> endpoint(endpoint); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{</ mermaid >}} @@ -324,17 +327,7 @@ client_address=10.240.0.5 시각적으로: -``` - client - | - lb VIP - / ^ - v / -health check ---> node 1 node 2 <--- health check - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) 이것은 어노테이션을 설정하여 테스트할 수 있다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 490f6ff18d..a253f04a0b 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml 이는 `zk-hs` 헤드리스 서비스, `zk-cs` 서비스, `zk-pdb` PodDisruptionBudget과 `zk` 스테이트풀셋을 생성한다. -```shell +``` service/zk-hs created service/zk-cs created poddisruptionbudget.policy/zk-pdb created @@ -98,7 +98,7 @@ kubectl get pods -w -l app=zk `zk-2` 파드가 Running and Ready 상태가 되면, `CTRL-C`를 눌러 kubectl을 종료하자. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -135,7 +135,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname; done 스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`, `zk-2`로 정한다. -```shell +``` zk-0 zk-1 zk-2 @@ -151,7 +151,7 @@ for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeepe 식별자는 자연수이고, 순번 인덱스들도 음수가 아니므로, 순번에 1을 더하여 순번을 만들 수 있다. -```shell +``` myid zk-0 1 myid zk-1 @@ -169,7 +169,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done `zk-hs` 서비스는 모든 파드를 위한 도메인인 `zk-hs.default.svc.cluster.local`을 만든다. -```shell +``` zk-0.zk-hs.default.svc.cluster.local zk-1.zk-hs.default.svc.cluster.local zk-2.zk-hs.default.svc.cluster.local @@ -188,7 +188,7 @@ kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg 연관된다. 이들은 `zk` 스테이트풀셋의 파드의 FQDNS을 설정한다. -```shell +``` clientPort=2181 dataDir=/var/lib/zookeeper/data dataLogDir=/var/lib/zookeeper/log @@ -212,7 +212,9 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 합의 프로토콜에서 각 참여자의 식별자는 고유해야 한다. Zab 프로토콜에 두 참여자가 동일한 고유 식별자로 요청해서는 안된다. 이는 시스템 프로세스가 어떤 프로세스가 어떤 데이터를 커밋했는지 동의하도록 하기 위해 필수적이다. 동일 순번으로 두 개의 파드가 실행했다면 두 ZooKeeper 서버는 모두 동일한 서버로 식별된다. ```shell kubectl get pods -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -236,7 +238,7 @@ ZooKeeper 서버의 FQDN은 단일 엔드포인트로 확인되고 해당 엔드포인트는 `myid` 파일에 구성된 식별자를 가진 고유한 ZooKeeper 서버가 된다. -```shell +``` zk-0.zk-hs.default.svc.cluster.local zk-1.zk-hs.default.svc.cluster.local zk-2.zk-hs.default.svc.cluster.local @@ -244,7 +246,7 @@ zk-2.zk-hs.default.svc.cluster.local 이것은 ZooKeeper의 `zoo.cfg` 파일에 `servers` 속성이 정확히 구성된 앙상블로 나타나는 것을 보증한다. -```shell +``` server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888 server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888 server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 @@ -260,7 +262,8 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888 ```shell kubectl exec zk-0 zkCli.sh create /hello world - +``` +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -276,7 +279,7 @@ kubectl exec zk-1 zkCli.sh get /hello `zk-0`에서 생성한 그 데이터는 앙상블 내에 모든 서버에서 사용할 수 있다. -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -307,6 +310,9 @@ ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상 ```shell kubectl delete statefulset zk +``` + +``` statefulset.apps "zk" deleted ``` @@ -318,7 +324,7 @@ kubectl get pods -w -l app=zk `zk-0`이 완전히 종료되면 `CTRL-C`를 이용해 kubectl을 종료하자. -```shell +``` zk-2 1/1 Terminating 0 9m zk-0 1/1 Terminating 0 11m zk-1 1/1 Terminating 0 10m @@ -349,7 +355,7 @@ kubectl get pods -w -l app=zk `zk-2` 파드가 Running과 Ready가 되면 `CTRL-C`를 이용하여 kubectl을 종료한다. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 0/1 Pending 0 0s zk-0 0/1 Pending 0 0s @@ -377,7 +383,7 @@ kubectl exec zk-2 zkCli.sh get /hello `zk` 스테이트풀셋의 모든 파드를 종료하고 재생성했음에도, 앙상블은 여전히 원래 값을 돌려준다. -```shell +``` WATCHER:: WatchedEvent state:SyncConnected type:None path:null @@ -422,7 +428,7 @@ kubectl get pvc -l app=zk `스테이트풀셋`의 파드를 재생성할 때에 파드의 퍼시스턴트볼륨도 다시 마운트한다. -```shell +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h @@ -457,6 +463,8 @@ ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 ```shell kubectl get sts zk -o yaml +``` +``` … command: - sh @@ -499,7 +507,7 @@ kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties 아래 로깅 구성은 ZooKeeper가 모든 로그를 표준 출력 스트림으로 처리하게 한다. -```shell +``` zookeeper.root.logger=CONSOLE zookeeper.console.threshold=INFO log4j.rootLogger=${zookeeper.root.logger} @@ -519,7 +527,7 @@ kubectl logs zk-0 --tail 20 `kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰인 애플리케이션 로그를 볼 수 있다. -```shell +``` 2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740 2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client) 2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749 @@ -575,7 +583,7 @@ kubectl exec zk-0 -- ps -elf `securityContext` 오브젝트의 `runAsUser` 필드 값이 1000 이므로 루트 사용자로 실행하는 대신 ZooKeeper 프로세스는 ZooKeeper 사용자로 실행된다. -```shell +``` F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground 0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg @@ -591,7 +599,7 @@ kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data `securityContext` 오브젝트의 `fsGroup` 필드 값이 1000 이므로, 파드의 퍼시스턴트 볼륨의 소유권은 ZooKeeper 그룹으로 지정되어 ZooKeeper 프로세스에서 읽고 쓸 수 있다. -```shell +``` drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ``` @@ -613,7 +621,8 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ```shell kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]' - +``` +``` statefulset.apps/zk patched ``` @@ -621,7 +630,8 @@ statefulset.apps/zk patched ```shell kubectl rollout status sts/zk - +``` +``` waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664... Waiting for 1 pods to be ready... Waiting for 1 pods to be ready... @@ -640,7 +650,9 @@ statefulset rolling update complete 3 pods at revision zk-5db4499664... ```shell kubectl rollout history sts/zk +``` +``` statefulsets "zk" REVISION 1 @@ -651,7 +663,9 @@ REVISION ```shell kubectl rollout undo sts/zk +``` +``` statefulset.apps/zk rolled back ``` @@ -671,7 +685,7 @@ kubectl exec zk-0 -- ps -ef 컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며 ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다. -```shell +``` UID PID PPID C STIME TTY TIME CMD zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg @@ -691,7 +705,7 @@ kubectl exec zk-0 -- pkill java ZooKeeper 프로세스의 종료는 부모 프로세스의 종료를 일으킨다. 컨테이너 `재시작정책`이 Always이기 때문에 부모 프로세스를 재시작했다. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 21m zk-1 1/1 Running 0 20m @@ -731,7 +745,7 @@ zk-0 1/1 Running 1 29m 검사는 ZooKeeper의 `ruok` 4 글자 단어를 이용해서 서버의 건강을 테스트하는 배쉬 스크립트를 호출한다. -```bash +``` OK=$(echo ruok | nc 127.0.0.1 $1) if [ "$OK" == "imok" ]; then exit 0 @@ -758,7 +772,9 @@ ZooKeeper의 활성도 검사에 실패하면, ```shell kubectl get pod -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 0 1h zk-1 1/1 Running 0 1h @@ -823,7 +839,7 @@ for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; `zk` `스테이트풀셋`에 모든 파드는 다른 노드에 배포된다. -```shell +``` kubernetes-node-cxpk kubernetes-node-a5aq kubernetes-node-2g2d @@ -882,7 +898,7 @@ kubectl get pdb zk-pdb `max-unavailable` 필드는 쿠버네티스가 `zk` `스테이트풀셋`에서 최대 1개의 파드는 언제든지 가용하지 않을 수 있음을 나타낸다. -```shell +``` NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE zk-pdb N/A 1 1 ``` @@ -897,7 +913,9 @@ kubectl get pods -w -l app=zk ```shell for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done +``` +``` kubernetes-node-pb41 kubernetes-node-ixsl kubernetes-node-i4c4 @@ -908,6 +926,9 @@ kubernetes-node-i4c4 ```shell kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +``` + +``` node "kubernetes-node-group-pb41" cordoned WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-group-pb41, kube-proxy-kubernetes-node-group-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz @@ -918,7 +939,7 @@ node "kubernetes-node-group-pb41" drained 클러스터에 4개 노드가 있기 때문에 `kubectl drain`이 성공하여 `zk-0`을 다른 노드로 재스케쥴링 된다. -```shell +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -940,7 +961,9 @@ zk-0 1/1 Running 0 1m ```shell kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned +``` +``` WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74 pod "zk-1" deleted node "kubernetes-node-ixsl" drained @@ -950,7 +973,9 @@ node "kubernetes-node-ixsl" drained ```shell kubectl get pods -w -l app=zk +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h @@ -978,6 +1003,8 @@ zk-1 0/1 Pending 0 0s ```shell kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +``` +``` node "kubernetes-node-i4c4" cordoned WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog @@ -999,7 +1026,7 @@ kubectl exec zk-0 zkCli.sh get /hello `PodDisruptionBudget`이 존중되기 때문에 서비스는 여전히 가용하다. -```shell +``` WatchedEvent state:SyncConnected type:None path:null world cZxid = 0x200000002 @@ -1019,7 +1046,8 @@ numChildren = 0 ```shell kubectl uncordon kubernetes-node-pb41 - +``` +``` node "kubernetes-node-pb41" uncordoned ``` @@ -1027,7 +1055,8 @@ node "kubernetes-node-pb41" uncordoned ```shell kubectl get pods -w -l app=zk - +``` +``` NAME READY STATUS RESTARTS AGE zk-0 1/1 Running 2 1h zk-1 1/1 Running 0 1h diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 719c998366..6b7c019d7f 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml 위의 명령어는 - [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) + {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}} 오브젝트와 관련된 - [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + {{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}} 오브젝트를 생성한다. 레플리카셋은 다섯 개의 - [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며, + {{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며, 각 파드는 Hello World 애플리케이션을 실행한다. 1. 디플로이먼트에 대한 정보를 확인한다.