diff --git a/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md index d936d7c767..d6df46ac55 100644 --- a/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md +++ b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md @@ -142,7 +142,7 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에 # 다가오는 릴리스 웨비나 -이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 9월 7일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요. +이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 10월 5일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요. # 참여하기 diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 5daed12077..5ceb5d98ce 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -122,6 +122,9 @@ kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다. kubectl cordon $NODENAME ``` +보다 자세한 내용은 [안전하게 노드를 드레인(drain)하기](/docs/tasks/administer-cluster/safely-drain-node/) +를 참고한다. + {{< note >}} {{< glossary_tooltip term_id="daemonset" >}}에 포함되는 일부 파드는 스케줄 불가 노드에서 실행될 수 있다. 일반적으로 데몬셋은 워크로드 애플리케이션을 @@ -174,7 +177,7 @@ kubectl describe node 대신 코드화된 노드는 사양에 스케줄 불가로 표시된다. {{< /note >}} -노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다. +쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다. ```json "conditions": [ @@ -189,20 +192,30 @@ kubectl describe node ] ``` -ready 컨디션의 상태가 `pod-eviction-timeout` ({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. +ready 컨디션의 `status`가 `pod-eviction-timeout` +({{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" +>}}에 전달된 인수)보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, +[노드 컨트롤러](#node-controller)가 해당 노드에 할당된 전체 파드에 대해 +{{< glossary_tooltip text="API를 이용한 축출" term_id="api-eviction" >}} +을 트리거한다. 기본 축출 타임아웃 기간은 +**5분** 이다. +노드에 접근이 불가할 때와 같은 경우, API 서버는 노드 상의 kubelet과 통신이 불가하다. +API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. +그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다. -노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 -강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 +노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. +파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 -apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. +API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다. -노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는 +노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 [테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다. 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. -또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. +또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 +{{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다. 자세한 내용은 [컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다. @@ -222,8 +235,34 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 ### 정보 -커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. -이 정보는 Kubelet에 의해 노드로부터 수집된다. +커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. + +이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다. + +## 하트비트 + +쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를 +판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다. + +노드에는 두 가지 형태의 하트비트가 있다. + +* 노드의 `.status`에 대한 업데이트 +* `kube-node-lease` + {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트. + 각 노드는 연관된 리스 오브젝트를 갖는다. + +노드의 `.status`와 비교해서, 리스는 경량의 리소스이다. +큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다. + +kubelet은 노드의 `.status` 생성과 업데이트 및 +관련된 리스의 업데이트를 담당한다. + +- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다. + 노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다. +- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다. + 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다. + 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다. + ### 노드 컨트롤러 @@ -241,39 +280,15 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 다음을 담당한다. -- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가 - 하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady - 컨디션을 ConditionUnknown으로 업데이트 한다. -- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다. - ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, - 파드를 축출하기 시작하는 값은 5분이다. +- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다. + 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다. +- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서 + [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다. + 기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. -#### 하트비트 - -쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다. - -하트비트의 두 가지 형태는 `NodeStatus` 와 -[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)이다. -각 노드에는 `kube-node-lease` 라는 -{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다. -리스는 경량 리소스로, 클러스터가 확장될 때 -노드의 하트비트 성능을 향상 시킨다. - -kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 -의무가 있다. - -- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우, - `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트 - 주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초 - 보다 훨씬 길다. -- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기). - 리스 업데이트는 `NodeStatus` 업데이트와는 - 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 - 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다. - -#### 안정성 +#### 축출 빈도 한계 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여 @@ -281,8 +296,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 -체크한다(NodeReady 컨디션은 ConditionUnknown 또는 -ConditionFalse 다). +체크한다(NodeReady 컨디션은 `ConditionUnknown` 또는 +`ConditionFalse` 다). - 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold` (기본값 0.55)가 되면 축출 속도가 감소한다. - 클러스터가 작으면 (즉 `--large-cluster-size-threshold` @@ -292,16 +307,15 @@ ConditionFalse 다). 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. -만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, -오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다. +만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상, +축출 매커니즘은 영역 별 가용성을 고려하지 않는다. 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 `--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 -완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. -이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 -복원될 때까지 모든 축출을 중지하는 것으로 여긴다. +완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다. +이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.) 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다. @@ -309,7 +323,7 @@ ConditionFalse 다). {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. -### 노드 용량 +## 리소스 용량 추적 {#node-capacity} 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 양과 CPU의 수를 추적한다. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 5ae2aafffd..39ef2f2dcb 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -17,8 +17,8 @@ weight: 60 -클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 -로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, +클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가 +로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, 쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. ## 쿠버네티스의 기본 로깅 @@ -136,7 +136,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다. -로깅 에이전트는 모든 노드에서 실행해야 하므로, 에이전트는 +로깅 에이전트는 모든 노드에서 실행되어야 하므로, 에이전트를 `DaemonSet` 으로 동작시키는 것을 추천한다. 노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다. @@ -262,4 +262,4 @@ fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](http ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) -모든 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. +애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index b72d38a360..3f6e103ba7 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -1,4 +1,6 @@ --- + + title: 클러스터 네트워킹 content_type: concept weight: 50 @@ -89,18 +91,6 @@ VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모 프로젝트 [Antrea](https://github.com/vmware-tanzu/antrea)는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다. Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다. -### Apstra의 AOS - -[AOS](https://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다. - -AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다. - -AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수 있는 풍부한 REST API 엔드포인트 셋을 제공한다. 네트워크 설계에 사용된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 클라우드와 퍼블릭 클라우드 모두에 대한 엔드-투-엔드 관리 시스템을 향상시킬 수 있다. - -AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다. - -AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. https://www.apstra.com/products/how-it-works/ - ### 쿠버네티스용 AWS VPC CNI [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다. @@ -114,15 +104,6 @@ AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다 Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)에서 기본적으로 사용할 수 있다. - -### Big Switch Networks의 빅 클라우드 패브릭(Big Cloud Fabric) - -[빅 클라우드 패브릭](https://www.bigswitch.com/container-network-automation)은 클라우드 네이티브 네트워킹 아키텍처로, 프라이빗 클라우드/온-프레미스 환경에서 쿠버네티스를 실행하도록 디자인되었다. 통합된 물리 및 가상 SDN을 사용하여, 빅 클라우드 패브릭은 로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 내재한 컨테이너 네트워킹 문제를 해결한다. - -빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다. - -가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. - ### 캘리코 [캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다. @@ -267,7 +248,7 @@ Lars Kellogg-Stedman이 제공하는 [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. -Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. +Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. ### OVN4NFV-K8s-Plugin (OVN 기반의 CNI 컨트롤러 & 플러그인) diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 841feb8fb3..0225ba7778 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -61,6 +61,11 @@ v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 있어야 한다. +{{< note >}} +{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵 +또는 다른 API 오브젝트를 참조할 수 없다. +{{< /note >}} + 다음은 단일 값을 가진 키와, 값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의 예시이다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 3084651390..fa7ec69fc9 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -182,8 +182,8 @@ kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을 플래그의 값으로 사용된다. - 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고 - 100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 총 CPU - 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다. + 100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 마이크로초 단위의 + 총 CPU 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다. {{< note >}} 기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다. @@ -338,6 +338,9 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: @@ -345,6 +348,12 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + volumes: + - name: ephemeral + emptyDir: {} ``` ### 임시-스토리지 요청이 있는 파드의 스케줄링 방법 diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index f89d873a37..64b6bc3395 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -73,32 +73,6 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - 디버깅을 위해 레이블을 조작할 수 있다. (레플리카셋과 같은) 쿠버네티스 컨트롤러와 서비스는 셀렉터 레이블을 사용해 파드를 선택하기 때문에, 관련된 레이블을 파드에서 삭제하는 것은 컨트롤러로부터 관리되거나 서비스로부터 트래픽을 전달받는 것을 중단시킨다. 만약 이미 존재하는 파드의 레이블을 삭제한다면, 파드의 컨트롤러는 그 자리를 대신할 새로운 파드를 생성한다. 이것은 이전에 "살아 있는" 파드를 "격리된" 환경에서 디버그할 수 있는 유용한 방법이다. 레이블을 상호적으로 추가하고 삭제하기 위해서, [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)를 사용할 수 있다. -## 컨테이너 이미지 - -[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다. - -- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다. - -- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다. - -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_. - -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_. - -- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다. - -{{< note >}} -컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다. -{{< /note >}} - -{{< note >}} -운영 환경에서 컨테이너를 생성할 때 `:latest` 태그의 사용을 피하는 것이 좋은데, 이는 어떠한 버전의 이미지가 실행 중인지 추적하기가 어렵고, 적절히 롤백하기가 더 어려워지기 때문이다. -{{< /note >}} - -{{< note >}} -레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다. -{{< /note >}} - ## kubectl 사용하기 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 330e89edac..8c0630c4b2 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -77,7 +77,7 @@ weight: 30 시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) 리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의 유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다. -시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다. +시크릿 타입은 여러 종류의 기밀 데이터를 프로그래밍 방식으로 용이하게 처리하기 위해 사용된다. 쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다. 이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에 @@ -212,7 +212,8 @@ data: kubectl create secret docker-registry secret-tiger-docker \ --docker-username=tiger \ --docker-password=pass113 \ - --docker-email=tiger@acme.com + --docker-email=tiger@acme.com \ + --docker-server=my-registry.example:5000 ``` 이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. @@ -222,15 +223,21 @@ kubectl create secret docker-registry secret-tiger-docker \ ```json { - "auths": { - "https://index.docker.io/v1/": { - "username": "tiger", - "password": "pass113", - "email": "tiger@acme.com", - "auth": "dGlnZXI6cGFzczExMw==" - } - } + "apiVersion": "v1", + "data": { + ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" + }, + "kind": "Secret", + "metadata": { + "creationTimestamp": "2021-07-01T07:30:59Z", + "name": "secret-tiger-docker", + "namespace": "default", + "resourceVersion": "566718", + "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" + }, + "type": "kubernetes.io/dockerconfigjson" } + ``` ### 기본 인증 시크릿 @@ -834,6 +841,9 @@ kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한 파드가 포함된다. kubelet의 `--manifest-url` 플래그, `--config` 플래그 또는 kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로 생성된 파드는 포함하지 않는다. +{{< glossary_tooltip text="스태틱(static) 파드" term_id="static-pod" >}}의 `spec`은 컨피그맵 +또는 다른 API 오브젝트를 참조할 수 없다. + 시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경 변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을 @@ -1252,3 +1262,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 +- [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 749eb6fbb8..18ed0aadd3 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` -서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. +서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 9a22f2f3e5..5ab09dd64a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -39,14 +39,6 @@ weight: 10 배치할 수 있는 위치에 대한 추가 규칙이 있다. 태그를 지정하지 않으면, 쿠버네티스는 태그 `latest` 를 의미한다고 가정한다. -{{< caution >}} -프로덕션에서 컨테이너를 배포할 때는 `latest` 태그를 사용하지 않아야 한다. -실행 중인 이미지 버전을 추적하기가 어렵고 -이전에 잘 동작하던 버전으로 롤백하기가 더 어렵다. - -대신, `v1.42.0` 과 같은 의미있는 태그를 지정한다. -{{< /caution >}} - ## 이미지 업데이트 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}, @@ -57,13 +49,62 @@ weight: 10 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 이미지에 대한 풀을 생략하게 한다. -만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. +### 이미지 풀(pull) 정책 -- 컨테이너의 `imagePullPolicy`를 `Always`로 설정. -- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용, - 쿠버네티스는 정책을 `Always`로 설정한다. -- `imagePullPolicy`와 사용할 이미지의 태그를 생략. -- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. +컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 +[kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. + +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. + +`IfNotPresent` +: 이미지가 로컬에 없는 경우에만 내려받는다. + +`Always` +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 + [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. + 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. + 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 + 컨테이너를 기동할 때 사용한다. + +`Never` +: kubelet은 이미지를 가져오려고 시도하지 않는다. 이미지가 어쨌든 이미 로컬에 존재하는 + 경우, kubelet은 컨테이너 기동을 시도한다. 이외의 경우 기동은 실패한다. + 보다 자세한 내용은 [미리 내려받은 이미지](#pre-pulled-images)를 참조한다. + +이미지 제공자에 앞서 깔린 캐시의 의미 체계는 레지스트리에 안정적으로 접근할 수 있는 한, +`imagePullPolicy: Always`인 경우 조차도 효율적이다. +컨테이너 런타임은 노드에 이미 존재하는 이미지 레이어를 알고 +다시 내려받지 않는다. + +{{< note >}} +프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. + +대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. +{{< /note >}} + +파드가 항상 컨테이너 이미지의 같은 버전을 사용하는 것을 확실히 하려면, +이미지의 다이제스트를 명기할 수 있다. +`:`를 `@`로 교체한다. +(예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. + +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. +이는 레지스트리에서 태그가 변경되는 일이 발생해도 +구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. + +#### 기본 이미지 풀 정책 {#imagepullpolicy-defaulting} + +사용자(또는 컨트롤러)가 신규 파드를 API 서버에 요청할 때, +특정 조건에 부합하면 클러스터가 `imagePullPolicy` 필드를 설정한다. + +- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그가 + `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. +- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, + `imagePullPolicy`는 자동으로 `Always`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -75,7 +116,16 @@ weight: 10 처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다. {{< /note >}} -`imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. +#### 이미지 풀 강제 + +이미지를 내려받도록 강제하려면, 다음 중 한가지 방법을 사용한다. + +- 컨테이너의 `imagePullPolicy`를 `Always`로 설정한다. +- `imagePullPolicy`를 생략하고 사용할 이미지 태그로 `:latest`를 사용한다. + 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. +- `imagePullPolicy`와 사용할 이미지의 태그를 생략한다. + 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. +- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. ### 이미지풀백오프(ImagePullBackOff) @@ -208,7 +258,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. -### 미리 내려받은 이미지 +### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 @@ -328,6 +378,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다. + ## {{% heading "whatsnext" %}} * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. 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 a2326c71dd..7658464ec0 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 @@ -1,5 +1,5 @@ --- -title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기 +title: 쿠버네티스 API 애그리게이션 레이어(aggregation layer) @@ -11,7 +11,7 @@ weight: 10 애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. -추가 API는 [서비스-카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. +추가 API는 [메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다. @@ -34,5 +34,6 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). * 다음에, [확장 API 서버를 구성해서](/ko/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. -* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. -* [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. +* API 레퍼런스에서 [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)에 대해 읽어본다. + +대안으로, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. 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 0357ac7619..e6e0203eb9 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 @@ -35,11 +35,10 @@ weight: 10 커스텀 리소스를 *커스텀 컨트롤러* 와 결합하면, 커스텀 리소스가 진정한 _선언적(declarative) API_ 를 제공하게 된다. -[선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 리소스의 의도한 상태를 -_선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트의 현재 상태를 의도한 상태와 -동기화 상태로 유지하려고 한다. 컨트롤러는 구조화된 데이터를 사용자가 -원하는 상태의 레코드로 해석하고 지속적으로 -이 상태를 유지한다. +쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 +책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다. +쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다. +이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다. 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만 @@ -167,7 +166,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. | CRD | 애그리게이트 API | | --------------------------- | -------------- | -| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | Go로 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. | +| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. | | 실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다. | 추가 서비스를 생성하면 실패할 수 있다. | | CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다. | 업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다. | | 여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다. | 인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다. | diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 80ed86c2ec..d3ac7a4212 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -114,6 +114,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 * [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 +* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를 사용하여 직접 구현하기 diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index cc387c2f02..8d1cb3ee05 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -32,7 +32,7 @@ weight: 40 서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다. -스토리지에 etcd를 사용하여 확장 API 서버와 컨트롤러로 구현된다. 또한 쿠버네티스 1.7 이상에서 제공하는 [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하여 API를 제공한다. +이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
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 cf1f5675bb..c090b171f4 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 @@ -81,12 +81,11 @@ deployment.apps/nginx-deployment created * `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스`를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터 * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지 -오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. -예를 들어, 파드에 대한 `spec` 포맷은 -[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 -[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. +오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. +예를 들어, API 내 파드에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 대한 레퍼런스에서, +디플로이먼트에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)에 대한 레퍼런스에서 확인할 수 있다. +해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다. ## {{% heading "whatsnext" %}} 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 049b30a1f7..fb2e52534c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -59,6 +59,9 @@ kube-system Active 1d * `kube-system` 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다. * `kube-node-lease` 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스 + * `kube-node-lease` 이 네임스페이스는 각 노드와 연관된 [리스](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) + 오브젝트를 갖는다. 노드 리스는 kubelet이 [하트비트](/ko/docs/concepts/architecture/nodes/#하트비트)를 + 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다. ### 요청에 네임스페이스 설정하기 diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index 1e6a007cdf..d64358ec64 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -125,7 +125,7 @@ spec: 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의 레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 -점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다. +점을 제외하고는 `requiredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingRequiredDuringExecution` 를 제공할 계획이다. 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 1ac3b81262..c3dcf84727 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -93,9 +93,9 @@ shape: ``` yaml resources: - - name: CPU + - name: cpu weight: 1 - - name: Memory + - name: memory weight: 1 ``` @@ -105,9 +105,9 @@ resources: resources: - name: intel.com/foo weight: 5 - - name: CPU + - name: cpu weight: 3 - - name: Memory + - name: memory weight: 1 ``` @@ -124,16 +124,16 @@ resources: ``` intel.com/foo : 2 -Memory: 256MB -CPU: 2 +memory: 256MB +cpu: 2 ``` 리소스의 가중치는 다음과 같다. ``` intel.com/foo : 5 -Memory: 1 -CPU: 3 +memory: 1 +cpu: 3 ``` FunctionShapePoint {{0, 0}, {100, 10}} @@ -143,13 +143,13 @@ FunctionShapePoint {{0, 0}, {100, 10}} ``` Available: intel.com/foo: 4 - Memory: 1 GB - CPU: 8 + memory: 1 GB + cpu: 8 Used: intel.com/foo: 1 - Memory: 256MB - CPU: 1 + memory: 256MB + cpu: 1 ``` 노드 점수는 다음과 같다. @@ -159,16 +159,16 @@ intel.com/foo = resourceScoringFunction((2+1),4) = (100 - ((4-3)*100/4) = (100 - 25) = 75 # requested + used = 75% * available - = rawScoringFunction(75) - = 7 # floor(75/10) + = rawScoringFunction(75) + = 7 # floor(75/10) -Memory = resourceScoringFunction((256+256),1024) +memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 # requested + used = 50% * available = rawScoringFunction(50) = 5 # floor(50/10) -CPU = resourceScoringFunction((2+1),8) +cpu = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) @@ -183,12 +183,12 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) ``` Available: intel.com/foo: 8 - Memory: 1GB - CPU: 8 + memory: 1GB + cpu: 8 Used: intel.com/foo: 2 - Memory: 512MB - CPU: 6 + memory: 512MB + cpu: 6 ``` 노드 점수는 다음과 같다. @@ -207,7 +207,7 @@ Memory = resourceScoringFunction((256+512),1024) = rawScoringFunction(75) = 7 -CPU = resourceScoringFunction((2+6),8) +cpu = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index 9612159eb4..cf2fc529ce 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -139,7 +139,7 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 - 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소 (스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다. - TLS가 없다. - - 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다. + - 기본 포트는 8080이다. - 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다. - 요청이 인증 및 인가 모듈을 **우회한다**. - 요청이 어드미션 제어 모듈(들)에 의해 처리된다. diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 47d0548a7e..dd81fe6b2c 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -60,6 +60,7 @@ Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | +Oracle Cloud Infrastructure | https://www.oracle.com/security/ | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | {{< /table >}} 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 2f5a9064da..2b70f86d54 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 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다. +[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)이 필요하다. {{< note >}} 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성, 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서 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 dea7c35965..5b8dada435 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -217,13 +217,13 @@ DNS 정책은 파드별로 설정할 수 있다. - "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. 자세한 내용은 - [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers)에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 805260d159..e9e5f12a05 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -164,8 +164,8 @@ Events: 요청은 _p_ 경로에 일치한다. {{< note >}} 경로의 마지막 요소가 요청 경로에 있는 마지막 - 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 - `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} + 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 는 + `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 와는 일치하지 않는다). {{< /note >}} ### 예제 diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index d8926be00c..bd1bc328f8 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -154,6 +154,7 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto 의심스러운 경우, `kubectl describe` 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다. + __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다. 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을 @@ -252,7 +253,7 @@ spec: ``` 위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, -네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 +네임스페이스 `default` 에 레이블이 `role=db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다. 이 필드를 사용할 때 다음의 제한 사항이 적용된다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 230b716c78..e0b022185f 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -183,6 +183,13 @@ subsets: 위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로 라우팅된다. `192.0.2.42:9376` (TCP) +{{< note >}} +쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다. +셀렉터가 없는 서비스에 대해서 `kubectl proxy `과 같은 행위는 +이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를 +프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다. +{{< /note >}} + ExternalName 서비스는 셀렉터가 없고 DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다. @@ -242,6 +249,24 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 낮거나 0이면 DNS에 부하가 높아 관리하기가 어려워 질 수 있다. +본 페이지의 뒷 부분에서 다양한 kube-proxy 구현의 동작에 대해 읽을 수 있다. +우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이 +수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고, +이는 때로는 리부트 전까지 정리되지 않을 수도 있다. +그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹 +프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다. +비록 `kube-proxy` 실행 파일이 `cleanup` 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이 +아니기 때문에 구현된 그대로만 사용할 수 있다. + +### 구성 + +kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다. +- kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다. +- kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다. +- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, + 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. + 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다. + ### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace} 이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의 @@ -428,8 +453,7 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다. [도커 링크 -호환](https://docs.docker.com/userguide/dockerlinks/) 변수 -([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와 +호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고, 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다. diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 87d43ae09e..4bc8926e3b 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -130,8 +130,10 @@ Events: `Retain` 반환 정책은 리소스를 수동으로 반환할 수 있게 한다. 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스 된" 것으로 간주된다. 그러나 이전 요청자의 데이터가 여전히 볼륨에 남아 있기 때문에 다른 요청에 대해서는 아직 사용할 수 없다. 관리자는 다음 단계에 따라 볼륨을 수동으로 반환할 수 있다. 1. 퍼시스턴트볼륨을 삭제한다. PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재한다. -1. 관련 스토리지 자산의 데이터를 수동으로 삭제한다. -1. 연결된 스토리지 자산을 수동으로 삭제하거나 동일한 스토리지 자산을 재사용하려는 경우 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다. +2. 관련 스토리지 자산의 데이터를 수동으로 삭제한다. +3. 연결된 스토리지 자산을 수동으로 삭제한다. + +동일한 스토리지 자산을 재사용하려는 경우, 동일한 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다. #### Delete(삭제) @@ -412,11 +414,19 @@ spec: 접근 모드는 다음과 같다. -* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 -* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다 -* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 -* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다. - 쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다. +`ReadWriteOnce` +: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. + +`ReadWriteMany` +: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. + +`ReadWriteOncePod` +: 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. + + + +[퍼시스턴트 볼륨에 대한 단일 파드 접근 모드 소개](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/) 블로그 기사에서 이에 대해 보다 자세한 내용을 다룬다. + CLI에서 접근 모드는 다음과 같이 약어로 표시된다. @@ -509,7 +519,7 @@ PV는 `storageClassName` 속성을 대부분의 볼륨 유형의 경우 이 필드를 설정할 필요가 없다. [AWS EBS](/ko/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) 및 [Azure Disk](/ko/docs/concepts/storage/volumes/#azuredisk) 볼륨 블록 유형에 자동으로 채워진다. [로컬](/ko/docs/concepts/storage/volumes/#local) 볼륨에 대해서는 이를 명시적으로 설정해야 한다. {{< /note >}} -PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. +PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. 노드 어피니티를 명기하기 위해서는, PV의 `.spec`에 `nodeAffinity`를 설정한다. [퍼시스턴트볼륨](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) API 레퍼런스에 해당 필드에 대해 보다 자세한 내용이 있다. ### 단계(Phase) @@ -897,16 +907,15 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우 사용자는 PVC가 필요한 구성을 배포할 수 없음). - ## {{% heading "whatsnext" %}} - +## {{% heading "whatsnext" %}} * [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기 * [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 -### 참고 +### API 레퍼런스 {#reference} -* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) -* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) -* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) -* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) +본 페이지에 기술된 API에 대해서 다음을 읽어본다. + +* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) +* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 740929b05c..e2b684166f 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,6 +17,8 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. +추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=