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 36ece0d6d2..1831692bdf 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -21,7 +21,7 @@ aliases: 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다. -`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다. +`kubernetes` 서비스(`default` 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다. 컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 4ad2a7aaaa..cb65b2832a 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -27,7 +27,7 @@ weight: 10 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에 노드를 추가하는 두가지 주요 방법이 있다. 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록 -2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가 +2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가 노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. @@ -48,8 +48,8 @@ weight: 10 쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는 kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다. -노드가 정상이면(필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다. -그렇지 않으면, 해당 노드는 정상이 될때까지 모든 클러스터 활동에 +노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다. +그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에 대해 무시된다. {{< note >}} @@ -226,13 +226,14 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다. 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 -노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 -수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) -NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, -노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. -(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, -파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 -매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. +다음을 담당한다. +- 노드 다운과 같은 어떤 이유로 노드 컨트롤러가 + 하트비트 수신이 중단되는 경우 NodeStatus의 NodeReady + 컨디션을 ConditionUnknown으로 업데이트 한다. +- 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다. + ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, + 파드를 축출하기 시작하는 값은 5분이다. +노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. #### 하트비트 @@ -250,11 +251,12 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 - kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우, `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트 - 주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초 - 보다 훨씬 길다). + 주기는 5분으로, 연결할 수 없는 노드의 시간 제한인 40초 + 보다 훨씬 길다. - kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기). 리스 업데이트는 `NodeStatus` 업데이트와는 - 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다. + 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 + 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다. #### 안정성 @@ -264,13 +266,13 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 -체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). -상태가 불량한 노드의 일부가 최소 -`--unhealthy-zone-threshold` 기본값 0.55) 가 -되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 -`--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, -그렇지 않으면 축출 비율은 초당 -`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. +체크한다(NodeReady 컨디션은 ConditionUnknown 또는 +ConditionFalse 다.). +- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` + (기본값 0.55)가 되면 축출 비율은 감소한다. +- 클러스터가 작으면 (즉 `--large-cluster-size-threshold` + 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 + `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, @@ -299,8 +301,8 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 ### 노드 용량 -노드 오브젝트는 노드 리소스 용량에 대한 정보(예: 사용 가능한 메모리의 -양과 CPU의 수)를 추적한다. +노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 +양과 CPU의 수를 추적한다. 노드의 [자체 등록](#노드에-대한-자체-등록)은 등록하는 중에 용량을 보고한다. [수동](#수동-노드-관리)으로 노드를 추가하는 경우 추가할 때 노드의 용량 정보를 설정해야 한다. diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index 9893c76548..d61d111274 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/ 동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다. -URL을 구성 소스로 지정할 수도 있다. 이는 github에 체크인된 구성 파일에서 직접 배포하는 데 편리하다. +URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다. ```shell kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 73fcf62b98..50ef8b3632 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -42,8 +42,8 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob `spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData` 필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와 `binaryData` 는 모두 선택 사항이다. `data` 필드는 -UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를 -포함하도록 설계되었다. +UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 +데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다. 컨피그맵의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index def34dd231..17fd61c6a6 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -81,9 +81,9 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다. -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다. +- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `imagePullPolicy`는 자동으로 `Always`가 적용된다. 태그 값을 변경하더라도 이 값은 `IfNotPresent`로 업데이트 되지 _않는다_. -- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `IfNotPresent`가 적용된다. +- `imagePullPolicy`가 생략되어 있고, 이미지 태그가 존재하지만 `:latest`가 아니라면 `imagePullPolicy`는 자동으로 `IfNotPresent`가 적용된다. 태그가 나중에 제거되거나 `:latest`로 변경되더라도 `Always`로 업데이트 되지 _않는다_. - `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다. @@ -96,7 +96,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 {{< /note >}} {{< note >}} -기반이 되는 이미지 제공자의 캐시 방법은 `imagePullPolicy: Always`를 효율적으로 만든다. 예를 들어, 도커에서는 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다. +레지스트리가 안정적으로 동작하는 상황에서는, `imagePullPolicy: Always`로 설정되어 있더라도 기반 이미지 관리 도구의 캐싱 정책을 통해 이미지 풀(pull) 작업의 효율성을 높일 수 있다. 예를 들어, 도커를 사용하는 경우 이미지가 이미 존재한다면 풀(Pull) 시도는 빠르게 진행되는데, 이는 모든 이미지 레이어가 캐시되어 있으며 이미지 다운로드가 필요하지 않기 때문이다. {{< /note >}} ## kubectl 사용하기 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 2f1ae4a27c..fe7aca59aa 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -49,16 +49,32 @@ weight: 10 ## 이미지 업데이트 -기본 풀(pull) 정책은 `IfNotPresent`이며, 이것은 -{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 -존재하는 이미지에 대한 풀을 생략하게 한다. 만약 항상 풀을 강제하고 싶다면, -다음 중 하나를 수행하면 된다. +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}, +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}, 파드 또는 파드 +템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우 +기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull) +정책은 `IfNotPresent`로 설정된다. 이 정책은 +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 이미 존재하는 +이미지에 대한 풀을 생략하게 한다. + +만약 항상 풀을 강제하고 싶다면, 다음 중 하나를 수행하면 된다. - 컨테이너의 `imagePullPolicy`를 `Always`로 설정. -- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용. +- `imagePullPolicy`를 생략하고 `:latest`를 사용할 이미지의 태그로 사용, + 쿠버네티스는 정책을 `Always`로 설정한다. - `imagePullPolicy`와 사용할 이미지의 태그를 생략. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화. +{{< note >}} +컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 +설정되고 나중에 이미지 태그가 변경되더라도 업데이트되지 않는다. + +예를 들어, 태그가 `:latest`가 아닌 이미지로 디플로이먼트를 생성하고, +나중에 해당 디플로이먼트의 이미지를 `:latest` 태그로 업데이트하면 +`imagePullPolicy` 필드가 `Always` 로 변경되지 않는다. 오브젝트를 +처음 생성 한 후 모든 오브젝트의 풀 정책을 수동으로 변경해야 한다. +{{< /note >}} + `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. ## 이미지 인덱스가 있는 다중 아키텍처 이미지 diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 57a4f3d9d2..21b3183b99 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -102,27 +102,28 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 ## 자신만의 오퍼레이터 작성 {#writing-operator} -에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 직접 코딩할 수 있다. -[다음 내용](#다음-내용)에서는 클라우드 네이티브 오퍼레이터를 작성하는 데 -사용할 수 있는 라이브러리 및 도구에 대한 몇 가지 링크를 -찾을 수 있다. +에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 +직접 코딩할 수 있다. 또한 [쿠버네티스 API의 클라이언트](/ko/docs/reference/using-api/client-libraries/) 역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다. +다음은 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는 +몇 가지 라이브러리와 도구들이다. +{{% thirdparty-content %}} + +* [kubebuilder](https://book.kubebuilder.io/) 사용하기 +* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) +* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 + 사용하여 직접 구현하기 +* [오퍼레이터 프레임워크](https://operatorframework.io) ## {{% heading "whatsnext" %}} * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기 -* 기존 도구를 사용하여 자신만의 오퍼레이터를 작성해보자. 다음은 예시이다. - * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) 사용하기 - * [kubebuilder](https://book.kubebuilder.io/) 사용하기 - * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 - 사용하여 직접 구현하기 - * [오퍼레이터 프레임워크](https://operatorframework.io) 사용하기 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기 * 오퍼레이터 패턴을 소개한 [CoreOS 원본 글](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) 읽기 (이 링크는 원본 글에 대한 보관 버전임) * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index 944d7340ba..245da33db3 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -37,7 +37,7 @@ weight: 50 자동 생성된 필드, 그리고 오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다. -* 빌드, 릴리스, 또는 타임 스탬프, 릴리즈 ID, git 브랜치, +* 빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치, PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보. * 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터. 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 2044cf5135..da3cff2a89 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -32,7 +32,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다. -서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리즈 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다. +서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다. 레이블 예시: 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 f9e739d7a1..dba31a6c7f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -5,7 +5,7 @@ title: 노드에 파드 할당하기 content_type: concept -weight: 50 +weight: 20 --- 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 f23396d936..d11b7fe2ae 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -5,7 +5,7 @@ title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_type: concept -weight: 50 +weight: 30 --- diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index 412645e734..d39289106e 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -75,8 +75,8 @@ parameters: 사용자는 `PersistentVolumeClaim` 에 스토리지 클래스를 포함시켜 동적으로 프로비전된 스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 `volume.beta.kubernetes.io/storage-class` 어노테이션을 통해 수행되었다. 그러나 이 어노테이션은 -v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의 -`storageClassName` 필드를 사용할 수 있기에 대신하여 사용해야 한다. 이 필드의 값은 +v1.9부터는 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의 +`storageClassName` 필드를 사용해야 한다. 이 필드의 값은 관리자가 구성한 `StorageClass` 의 이름과 일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고) diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index c9b3ac80d9..5323182966 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -31,7 +31,8 @@ weight: 10 임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은 파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서 실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가 -더 이상 존재하지 않으면, 볼륨은 삭제된다. +더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만, +퍼시스턴트(persistent) 볼륨은 삭제하지 않는다. 기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index f6b9979d47..e19720491d 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -51,8 +51,8 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id= {{< note >}} `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 - 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 - 값 배열은 "value"만 포함한다. + 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며 + `value` 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} @@ -1037,7 +1037,7 @@ echo $? ## 카나리 디플로이먼트 -만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 +만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리스를 롤아웃 하기 위해서는 [리소스 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#카나리-canary-디플로이먼트)에 설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 516c22bfea..8697159261 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -224,7 +224,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 {{% tab name="Hugo 컨테이너" %}} {{< note >}} -아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경변수를 설정한다. +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다. {{< /note >}} 1. 로컬에서 이미지를 빌드한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index c294f2efb5..ff1727ffee 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -6,6 +6,7 @@ linkTitle: "레퍼런스" main_menu: true weight: 70 content_type: concept +no_list: true --- @@ -18,11 +19,17 @@ content_type: concept ## API 레퍼런스 +* [표준 용어집](/ko/docs/reference/glossary/) - 포괄적이고, 표준화 된 쿠버네티스 용어 목록 + + + * [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/) * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 +* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항 +* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/) -## API 클라이언트 라이브러리 +## 공식적으로 지원되는 클라이언트 라이브러리 프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서, [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다. @@ -32,22 +39,27 @@ content_type: concept - [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python) - [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java) - [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript) +- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp) +- [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell) -## CLI 레퍼런스 +## CLI * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. -## 컴포넌트 레퍼런스 +## 컴포넌트 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. - * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies) - * [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles) + +## 스케줄링 + +* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies) +* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles) ## 설계 문서 diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md index 9e23c5d767..0c910199b7 100644 --- a/content/ko/docs/reference/access-authn-authz/_index.md +++ b/content/ko/docs/reference/access-authn-authz/_index.md @@ -1,6 +1,6 @@ --- title: API 접근 제어 -weight: 20 +weight: 15 no_list: true --- diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md index 14025d0f71..d975db37b1 100644 --- a/content/ko/docs/reference/command-line-tools-reference/_index.md +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -1,4 +1,4 @@ --- -title: 커맨드 라인 도구 레퍼런스 +title: 컴포넌트 도구 weight: 60 --- diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 93683ae9b1..62fb53396c 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -242,6 +242,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | | `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index 565c3b4faf..e4c790c491 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -2,8 +2,21 @@ title: kube-proxy content_type: tool-reference weight: 30 +auto_generated: true --- + + + ## {{% heading "synopsis" %}} @@ -32,308 +45,308 @@ kube-proxy [flags] --azure-container-registry-config string -Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로. +

Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로.

---bind-address ip     기본값: 0.0.0.0 +--bind-address string     기본값: 0.0.0.0 -프록시 서버가 서비스할 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0'으로 설정, 모든 IPv6 인터페이스의 경우 '::'로 설정) +

프록시 서버가 서비스할 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0'으로 설정, 모든 IPv6 인터페이스의 경우 '::'로 설정)

--bind-address-hard-fail -true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다. +

true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다.

--cleanup -true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다. +

true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.

--cluster-cidr string -클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다 +

클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다

--config string -설정 파일의 경로. +

설정 파일의 경로.

--config-sync-period duration     기본값: 15m0s -apiserver의 설정이 갱신되는 빈도. 0보다 커야 한다. +

apiserver의 설정이 갱신되는 빈도. 0보다 커야 한다.

--conntrack-max-per-core int32     기본값: 32768 -CPU 코어당 추적할 최대 NAT 연결 수(한도(limit)를 그대로 두고 contrack-min을 무시하려면 0으로 설정한다)( +

CPU 코어당 추적할 최대 NAT 연결 수(한도(limit)를 그대로 두고 contrack-min을 무시하려면 0으로 설정한다)(

--conntrack-min int32     기본값: 131072 -conntrack-max-per-core와 관계없이 할당할 최소 conntrack 항목 수(한도를 그대로 두려면 conntrack-max-per-core값을 0으로 설정). +

conntrack-max-per-core와 관계없이 할당할 최소 conntrack 항목 수(한도를 그대로 두려면 conntrack-max-per-core값을 0으로 설정).

--conntrack-tcp-timeout-close-wait duration     기본값: 1h0m0s -CLOSE_WAIT 상태의 TCP 연결에 대한 NAT 시간 초과 +

CLOSE_WAIT 상태의 TCP 연결에 대한 NAT 시간 초과

--conntrack-tcp-timeout-established duration     기본값: 24h0m0s -설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지) +

설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지)

--detect-local-mode LocalMode -로컬 트래픽을 탐지하는 데 사용할 모드 +

로컬 트래픽을 탐지하는 데 사용할 모드

--feature-gates mapStringBool -알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍 집합. 옵션은 다음과 같다.
APIListChunking=true|false (BETA - 기본값=true)
APIPriorityAndFairness=true|false (ALPHA - 기본값=false)
APIResponseCompression=true|false (BETA - 기본값=true)
AllAlpha=true|false (ALPHA - 기본값=false)
AllBeta=true|false (BETA - 기본값=false)
AllowInsecureBackendProxy=true|false (BETA - 기본값=true)
AnyVolumeDataSource=true|false (ALPHA - 기본값=false)
AppArmor=true|false (BETA - 기본값=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 기본값=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - 기본값=false)
CPUManager=true|false (BETA - 기본값=true)
CRIContainerLogRotation=true|false (BETA - 기본값=true)
CSIInlineVolume=true|false (BETA - 기본값=true)
CSIMigration=true|false (BETA - 기본값=true)
CSIMigrationAWS=true|false (BETA - 기본값=false)
CSIMigrationAWSComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureDisk=true|false (BETA - 기본값=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFile=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - 기본값=false)
CSIMigrationGCE=true|false (BETA - 기본값=false)
CSIMigrationGCEComplete=true|false (ALPHA - 기본값=false)
CSIMigrationOpenStack=true|false (BETA - 기본값=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - 기본값=false)
CSIMigrationvSphere=true|false (BETA - 기본값=false)
CSIMigrationvSphereComplete=true|false (BETA - 기본값=false)
CSIStorageCapacity=true|false (ALPHA - 기본값=false)
CSIVolumeFSGroupPolicy=true|false (ALPHA - 기본값=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - 기본값=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 기본값=false)
DefaultPodTopologySpread=true|false (ALPHA - 기본값=false)
DevicePlugins=true|false (BETA - 기본값=true)
DisableAcceleratorUsageMetrics=true|false (ALPHA - 기본값=false)
DynamicKubeletConfig=true|false (BETA - 기본값=true)
EndpointSlice=true|false (BETA - 기본값=true)
EndpointSliceProxying=true|false (BETA - 기본값=true)
EphemeralContainers=true|false (ALPHA - 기본값=false)
ExpandCSIVolumes=true|false (BETA - 기본값=true)
ExpandInUsePersistentVolumes=true|false (BETA - 기본값=true)
ExpandPersistentVolumes=true|false (BETA - 기본값=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 기본값=false)
GenericEphemeralVolume=true|false (ALPHA - 기본값=false)
HPAScaleToZero=true|false (ALPHA - 기본값=false)
HugePageStorageMediumSize=true|false (BETA - 기본값=true)
HyperVContainer=true|false (ALPHA - 기본값=false)
IPv6DualStack=true|false (ALPHA - 기본값=false)
ImmutableEphemeralVolumes=true|false (BETA - 기본값=true)
KubeletPodResources=true|false (BETA - 기본값=true)
LegacyNodeRoleBehavior=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolation=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 기본값=false)
NodeDisruptionExclusion=true|false (BETA - 기본값=true)
NonPreemptingPriority=true|false (BETA - 기본값=true)
PodDisruptionBudget=true|false (BETA - 기본값=true)
PodOverhead=true|false (BETA - 기본값=true)
ProcMountType=true|false (ALPHA - 기본값=false)
QOSReserved=true|false (ALPHA - 기본값=false)
RemainingItemCount=true|false (BETA - 기본값=true)
RemoveSelfLink=true|false (ALPHA - 기본값=false)
RotateKubeletServerCertificate=true|false (BETA - 기본값=true)
RunAsGroup=true|false (BETA - 기본값=true)
RuntimeClass=true|false (BETA - 기본값=true)
SCTPSupport=true|false (BETA - 기본값=true)
SelectorIndex=true|false (BETA - 기본값=true)
ServerSideApply=true|false (BETA - 기본값=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - 기본값=false)
ServiceAppProtocol=true|false (BETA - 기본값=true)
ServiceNodeExclusion=true|false (BETA - 기본값=true)
ServiceTopology=true|false (ALPHA - 기본값=false)
SetHostnameAsFQDN=true|false (ALPHA - 기본값=false)
StartupProbe=true|false (BETA - 기본값=true)
StorageVersionHash=true|false (BETA - 기본값=true)
SupportNodePidsLimit=true|false (BETA - 기본값=true)
SupportPodPidsLimit=true|false (BETA - 기본값=true)
Sysctls=true|false (BETA - 기본값=true)
TTLAfterFinished=true|false (ALPHA - 기본값=false)
TokenRequest=true|false (BETA - 기본값=true)
TokenRequestProjection=true|false (BETA - 기본값=true)
TopologyManager=true|false (BETA - 기본값=true)
ValidateProxyRedirects=true|false (BETA - 기본값=true)
VolumeSnapshotDataSource=true|false (BETA - 기본값=true)
WarningHeaders=true|false (BETA - 기본값=true)
WinDSR=true|false (ALPHA - 기본값=false)
WinOverlay=true|false (ALPHA - 기본값=false)
WindowsEndpointSliceProxying=true|false (ALPHA - 기본값=false) +

알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍 집합. 옵션은 다음과 같다.
APIListChunking=true|false (BETA - 기본값=true)
APIPriorityAndFairness=true|false (ALPHA - 기본값=false)
APIResponseCompression=true|false (BETA - 기본값=true)
AllAlpha=true|false (ALPHA - 기본값=false)
AllBeta=true|false (BETA - 기본값=false)
AllowInsecureBackendProxy=true|false (BETA - 기본값=true)
AnyVolumeDataSource=true|false (ALPHA - 기본값=false)
AppArmor=true|false (BETA - 기본값=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 기본값=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - 기본값=false)
CPUManager=true|false (BETA - 기본값=true)
CRIContainerLogRotation=true|false (BETA - 기본값=true)
CSIInlineVolume=true|false (BETA - 기본값=true)
CSIMigration=true|false (BETA - 기본값=true)
CSIMigrationAWS=true|false (BETA - 기본값=false)
CSIMigrationAWSComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureDisk=true|false (BETA - 기본값=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFile=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - 기본값=false)
CSIMigrationGCE=true|false (BETA - 기본값=false)
CSIMigrationGCEComplete=true|false (ALPHA - 기본값=false)
CSIMigrationOpenStack=true|false (BETA - 기본값=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - 기본값=false)
CSIMigrationvSphere=true|false (BETA - 기본값=false)
CSIMigrationvSphereComplete=true|false (BETA - 기본값=false)
CSIStorageCapacity=true|false (ALPHA - 기본값=false)
CSIVolumeFSGroupPolicy=true|false (ALPHA - 기본값=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - 기본값=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 기본값=false)
DefaultPodTopologySpread=true|false (ALPHA - 기본값=false)
DevicePlugins=true|false (BETA - 기본값=true)
DisableAcceleratorUsageMetrics=true|false (ALPHA - 기본값=false)
DynamicKubeletConfig=true|false (BETA - 기본값=true)
EndpointSlice=true|false (BETA - 기본값=true)
EndpointSliceProxying=true|false (BETA - 기본값=true)
EphemeralContainers=true|false (ALPHA - 기본값=false)
ExpandCSIVolumes=true|false (BETA - 기본값=true)
ExpandInUsePersistentVolumes=true|false (BETA - 기본값=true)
ExpandPersistentVolumes=true|false (BETA - 기본값=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 기본값=false)
GenericEphemeralVolume=true|false (ALPHA - 기본값=false)
HPAScaleToZero=true|false (ALPHA - 기본값=false)
HugePageStorageMediumSize=true|false (BETA - 기본값=true)
HyperVContainer=true|false (ALPHA - 기본값=false)
IPv6DualStack=true|false (ALPHA - 기본값=false)
ImmutableEphemeralVolumes=true|false (BETA - 기본값=true)
KubeletPodResources=true|false (BETA - 기본값=true)
LegacyNodeRoleBehavior=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolation=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 기본값=false)
NodeDisruptionExclusion=true|false (BETA - 기본값=true)
NonPreemptingPriority=true|false (BETA - 기본값=true)
PodDisruptionBudget=true|false (BETA - 기본값=true)
PodOverhead=true|false (BETA - 기본값=true)
ProcMountType=true|false (ALPHA - 기본값=false)
QOSReserved=true|false (ALPHA - 기본값=false)
RemainingItemCount=true|false (BETA - 기본값=true)
RemoveSelfLink=true|false (ALPHA - 기본값=false)
RotateKubeletServerCertificate=true|false (BETA - 기본값=true)
RunAsGroup=true|false (BETA - 기본값=true)
RuntimeClass=true|false (BETA - 기본값=true)
SCTPSupport=true|false (BETA - 기본값=true)
SelectorIndex=true|false (BETA - 기본값=true)
ServerSideApply=true|false (BETA - 기본값=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - 기본값=false)
ServiceAppProtocol=true|false (BETA - 기본값=true)
ServiceNodeExclusion=true|false (BETA - 기본값=true)
ServiceTopology=true|false (ALPHA - 기본값=false)
SetHostnameAsFQDN=true|false (ALPHA - 기본값=false)
StartupProbe=true|false (BETA - 기본값=true)
StorageVersionHash=true|false (BETA - 기본값=true)
SupportNodePidsLimit=true|false (BETA - 기본값=true)
SupportPodPidsLimit=true|false (BETA - 기본값=true)
Sysctls=true|false (BETA - 기본값=true)
TTLAfterFinished=true|false (ALPHA - 기본값=false)
TokenRequest=true|false (BETA - 기본값=true)
TokenRequestProjection=true|false (BETA - 기본값=true)
TopologyManager=true|false (BETA - 기본값=true)
ValidateProxyRedirects=true|false (BETA - 기본값=true)
VolumeSnapshotDataSource=true|false (BETA - 기본값=true)
WarningHeaders=true|false (BETA - 기본값=true)
WinDSR=true|false (ALPHA - 기본값=false)
WinOverlay=true|false (ALPHA - 기본값=false)
WindowsEndpointSliceProxying=true|false (ALPHA - 기본값=false)

--healthz-bind-address ipport     기본값: 0.0.0.0:10256 -헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정). 사용 안 할 경우 빈칸으로 둠. +

헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정). 사용 안 할 경우 빈칸으로 둠.

-h, --help -kube-proxy에 대한 도움말. +

kube-proxy에 대한 도움말.

--hostname-override string -문자열 값이 있으면, 이 값을 실제 호스트네임 대신에 ID로 사용한다. +

문자열 값이 있으면, 이 값을 실제 호스트네임 대신에 ID로 사용한다.

--iptables-masquerade-bit int32     기본값: 14 -순수 iptable 프록시를 사용하는 경우 SNAT가 필요한 패킷을 표시하는 fwmark 스페이스 비트. [0, 31] 범위 안에 있어야 한다. +

순수 iptable 프록시를 사용하는 경우 SNAT가 필요한 패킷을 표시하는 fwmark 스페이스 비트. [0, 31] 범위 안에 있어야 한다.

--iptables-min-sync-period duration     기본값: 1s -엔드포인트 및 서비스가 변경될 때 iptable 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m'). +

엔드포인트 및 서비스가 변경될 때 iptable 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').

--iptables-sync-period duration     기본값: 30s -iptable 규칙을 새로 고치는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다. +

iptable 규칙을 새로 고치는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.

--ipvs-exclude-cidrs stringSlice -IPVS 규칙을 정리할 때 ipvs 프록시가 건드리지 않아야 하는 쉼표로 구분된 CIDR 목록. +

IPVS 규칙을 정리할 때 ipvs 프록시가 건드리지 않아야 하는 쉼표로 구분된 CIDR 목록.

--ipvs-min-sync-period duration -엔드포인트 및 서비스가 변경될 때 ipvs 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m'). +

엔드포인트 및 서비스가 변경될 때 ipvs 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').

--ipvs-scheduler string -프록시 모드가 ipvs인 경우 ipvs 스케줄러 유형. +

프록시 모드가 ipvs인 경우 ipvs 스케줄러 유형.

--ipvs-strict-arp -arp_ignore를 1로 설정하고 arp_annotes를 2로 설정하여 엄격한 ARP를 사용. +

arp_ignore를 1로 설정하고 arp_annotes를 2로 설정하여 엄격한 ARP를 사용.

--ipvs-sync-period duration     기본값: 30s -ipvs 규칙이 새로 갱신되는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다. +

ipvs 규칙이 새로 갱신되는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.

--ipvs-tcp-timeout duration -유휴 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m'). +

유휴 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').

--ipvs-tcpfin-timeout duration -FIN 패킷을 수신한 후 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m'). +

FIN 패킷을 수신한 후 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').

--ipvs-udp-timeout duration -IPVS UDP 패킷에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m'). +

IPVS UDP 패킷에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').

--kube-api-burst int32     기본값: 10 -쿠버네티스 api 서버와 통신하는 동안 사용할 burst. +

쿠버네티스 api 서버와 통신하는 동안 사용할 burst.

--kube-api-content-type string     기본값: "application/vnd.kubernetes.protobuf" -api 서버에 보낸 요청의 내용 유형. +

api 서버에 보낸 요청의 내용 유형.

--kube-api-qps float32     기본값: 5 -쿠버네티스 api 서버와 통신할 때 사용할 QPS. +

쿠버네티스 api 서버와 통신할 때 사용할 QPS.

--kubeconfig string -인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨). +

인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨).

--log-flush-frequency duration     기본값: 5s -로그 플러시 사이의 최대 시간 +

로그 플러시 사이의 최대 시간

--masquerade-all -순수 iptables 프록시를 사용하는 경우 서비스 클러스터 IP를 통해 전송된 모든 트래픽을 SNAT함(일반적으로 필요하지 않음). +

순수 iptables 프록시를 사용하는 경우 서비스 클러스터 IP를 통해 전송된 모든 트래픽을 SNAT함(일반적으로 필요하지 않음).

--master string -쿠버네티스 API 서버의 주소(kubeconfig의 모든 값 덮어쓰기). +

쿠버네티스 API 서버의 주소(kubeconfig의 모든 값 덮어쓰기).

--metrics-bind-address ipport     기본값: 127.0.0.1:10249 -메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것. +

메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것.

--nodeport-addresses stringSlice -NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다. +

NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.

--oom-score-adj int32     기본값: -999 -kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다. +

kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다.

--profiling -값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다. +

값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다.

--proxy-mode ProxyMode -사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다. +

사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다.

--proxy-port-range port-range -서비스 트래픽을 프록시하기 위해 사용할 수 있는 호스트 포트 범위(beginPort-endPort, single port 또는 beginPort+offset 포함). 만약 범위가 0, 0-0, 혹은 지정되지 않으면, 포트는 무작위로 선택된다. +

서비스 트래픽을 프록시하기 위해 사용할 수 있는 호스트 포트 범위(beginPort-endPort, single port 또는 beginPort+offset 포함). 만약 범위가 0, 0-0, 혹은 지정되지 않으면, 포트는 무작위로 선택된다.

--show-hidden-metrics-for-version string -숨겨진 메트릭을 표시할 이전 버전. +

숨겨진 메트릭을 표시할 이전 버전.

--udp-timeout duration     기본값: 250ms -유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함. +

유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.

--version version[=true] -버전 정보를 인쇄하고 종료. +

버전 정보를 인쇄하고 종료.

--write-config-to string -기본 구성 값을 이 파일에 옮겨쓰고 종료한다. +

기본 구성 값을 이 파일에 옮겨쓰고 종료한다.

diff --git a/content/ko/docs/reference/glossary/index.md b/content/ko/docs/reference/glossary/index.md index 9af1b3d078..024d8414ba 100755 --- a/content/ko/docs/reference/glossary/index.md +++ b/content/ko/docs/reference/glossary/index.md @@ -1,5 +1,5 @@ --- -title: 표준 용어집 +title: 용어집 layout: glossary noedit: true default_active_tag: fundamental diff --git a/content/ko/docs/reference/glossary/volume-plugin.md b/content/ko/docs/reference/glossary/volume-plugin.md new file mode 100644 index 0000000000..779f0303ca --- /dev/null +++ b/content/ko/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,19 @@ +--- +title: 볼륨 플러그인(Volume Plugin) +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + 볼륨 플러그인은 파드 내에서의 스토리지 통합을 가능하게 한다. + +aka: +tags: +- core-object +- storage +--- + 볼륨 플러그인은 {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 내에서의 스토리지 통합을 가능하게 한다. + + + +볼륨 플러그인을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 사용할 스토리지 볼륨을 연결하고 마운트할 수 있다. 볼륨 플러그인은 _인-트리(in tree)_ 혹은 _아웃-오브-트리(out of tree)_ 일 수 있다. _인-트리_ 플러그인은 쿠버네티스 코드 리포지터리의 일부이며 동일한 릴리즈 주기를 따른다. _아웃-오브-트리_ 플러그인은 독립적으로 개발된다. + diff --git a/content/ko/docs/reference/issues-security/_index.md b/content/ko/docs/reference/issues-security/_index.md index 596a6e01a4..12ac2f3759 100644 --- a/content/ko/docs/reference/issues-security/_index.md +++ b/content/ko/docs/reference/issues-security/_index.md @@ -1,4 +1,4 @@ --- title: 쿠버네티스 이슈와 보안 -weight: 10 +weight: 40 --- diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md index 7b6c2d720b..765adb6fe8 100755 --- a/content/ko/docs/reference/kubectl/_index.md +++ b/content/ko/docs/reference/kubectl/_index.md @@ -1,5 +1,5 @@ --- -title: "kubectl CLI" +title: "kubectl" weight: 60 --- diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 7ddfe5b095..3d8179a08a 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -17,7 +17,7 @@ KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/c 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. -설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. +설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고한다. diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 0f3f120d77..7b6942e119 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -185,8 +185,6 @@ profiles: - `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 선호한다. 익스텐션 포인트: `Score`. -- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다. - 익스텐션 포인트: `PreScore`, `Score`. - `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: `Filter`. diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md index 051fba4c5d..717b9cb2ac 100644 --- a/content/ko/docs/reference/setup-tools/_index.md +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- -title: 설치 도구 레퍼런스 +title: 설치 도구 weight: 50 --- diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md index 683f78000b..9211da1e0f 100644 --- a/content/ko/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md @@ -16,15 +16,15 @@ kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 ## 설치 방법 -kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다. +kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)를 참고한다. ## {{% heading "whatsnext" %}} -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다. -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다. -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다. -* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다. -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. -* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다. -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다. +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다. +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다. +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다. +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다. +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. diff --git a/content/ko/docs/reference/setup-tools/kubeadm/generated/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/generated/_index.md new file mode 100644 index 0000000000..7ebf753ae9 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/kubeadm/generated/_index.md @@ -0,0 +1,6 @@ +--- +title: "Kubeadm Generated" +weight: 10 +toc_hide: true +--- + diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools/_index.md similarity index 88% rename from content/ko/docs/reference/tools.md rename to content/ko/docs/reference/tools/_index.md index 97206f3be7..a38158bf14 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools/_index.md @@ -16,7 +16,7 @@ content_type: concept ## Kubeadm -[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태). +[`kubeadm`](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태). ## Minikube diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 427cebf529..423d82e0f2 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -1,7 +1,8 @@ --- -title: 쿠버네티스 API 개요 +title: API 개요 content_type: concept weight: 10 +no_list: true card: name: 레퍼런스 weight: 50 diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 189dbed654..3d825ebd08 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -55,7 +55,7 @@ content_type: concept 특정 kubelet을 나타내는 노드 오브젝트에 {{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다. 이러한 레이블에는 -[영역 정보](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다. +[영역 정보](/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다. 클러스터가 여러 영역 또는 지역에 걸쳐있는 경우, [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과 diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 827b407b84..52ab0fc94b 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -63,7 +63,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. ### containerd -이 섹션에는 `containerd` 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. +이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. 필수 구성 요소를 설치 및 구성한다. @@ -90,170 +90,63 @@ sudo sysctl --system containerd를 설치한다. {{< tabs name="tab-cri-containerd-installation" >}} -{{% tab name="Ubuntu 16.04" %}} +{{% tab name="Linux" %}} -```shell -# 도커의 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - -# (containerd 설치) -## 리포지터리 설정 -### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치 -sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common -``` +1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. -```shell -## 도커의 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - -``` +2. containerd 설정 -```shell -## 도커 apt 리포지터리 추가 -sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` + ```shell + sudo mkdir -p /etc/containerd + containerd config default | sudo tee /etc/containerd/config.toml + ``` -```shell -## containerd 설치 -sudo apt-get update && sudo apt-get install -y containerd.io -``` +3. containerd 재시작 -```shell -# containerd 구성 -sudo mkdir -p /etc/containerd -containerd config default | sudo tee /etc/containerd/config.toml -``` + ```shell + sudo systemctl restart containerd + ``` -```shell -# containerd 재시작 -sudo systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="Ubuntu 18.04/20.04" %}} - -```shell -# (containerd 설치) -sudo apt-get update && sudo apt-get install -y containerd -``` - -```shell -# containerd 구성 -sudo mkdir -p /etc/containerd -containerd config default | sudo tee /etc/containerd/config.toml -``` - -```shell -# containerd 재시작 -sudo systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="Debian 9+" %}} - -```shell -# (containerd 설치) -## 리포지터리 설정 -### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치 -sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common -``` - -```shell -## 도커의 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - -``` - -```shell -## 도커 apt 리포지터리 추가 -sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/debian \ - $(lsb_release -cs) \ - stable" -``` - -```shell -## containerd 설치 -sudo apt-get update && sudo apt-get install -y containerd.io -``` - -```shell -# 기본 containerd 구성 설정 -sudo mkdir -p /etc/containerd -containerd config default | sudo tee /etc/containerd/config.toml -``` - -```shell -# containerd 재시작 -sudo systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="CentOS/RHEL 7.4+" %}} - -```shell -# (containerd 설치) -## 리포지터리 설정 -### 필요한 패키지 설치 -sudo yum install -y yum-utils device-mapper-persistent-data lvm2 -``` - -```shell -## 도커 리포지터리 추가 -sudo yum-config-manager \ - --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo -``` - -```shell -# containerd 설치 -sudo yum update -y && sudo yum install -y containerd.io -``` - -```shell -## containerd 구성 -sudo mkdir -p /etc/containerd -containerd config default | sudo tee /etc/containerd/config.toml -``` - -```shell -# containerd 재시작 -sudo systemctl restart containerd -``` {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -
-Powershell 세션을 띄우고, `$Version` 환경 변수를 원하는 버전으로 설정(예: `$Version=1.4.3`)한 뒤, 다음 명령어를 실행한다. -
+PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다. -```powershell -# (containerd 설치) -# containerd 다운로드 -curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz -tar.exe xvf .\containerd-windows-amd64.tar.gz -``` +1. containerd 다운로드 -```powershell -# 추출 및 구성 -Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force -cd $Env:ProgramFiles\containerd\ -.\containerd.exe config default | Out-File config.toml -Encoding ascii + ```powershell + curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar. +gz + tar.exe xvf .\containerd-windows-amd64.tar.gz + ``` -# 구성을 검토한다. 설정에 따라 조정할 수 있다. -# - sandbox_image (쿠버네티스 pause 이미지) -# - cni bin_dir 및 conf_dir locations -Get-Content config.toml +2. 추출과 설정 -# (선택 사항이지만, 강력히 권장됨) containerd를 Windows Defender 검사 예외에 추가 -Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ``` + ```powershell + Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force + cd $Env:ProgramFiles\containerd\ + .\containerd.exe config default | Out-File config.toml -Encoding ascii + + # 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다. + # - sandbox_image (쿠버네티스 일시중지 이미지) + # - cni bin 폴더와 conf 폴더 위치 + Get-Content config.toml + + # (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외 + Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" + ``` + +3. containerd 실행 + + ```powershell + .\containerd.exe --register-service + Start-Service containerd + ``` -```powershell -# containerd 시작 -.\containerd.exe --register-service -Start-Service containerd -``` {{% /tab %}} {{< /tabs >}} -#### systemd {#containerd-systemd} +#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd} `/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다. @@ -264,8 +157,14 @@ Start-Service containerd SystemdCgroup = true ``` +이 변경 사항을 적용하는 경우 containerd를 재시작한다. + +```shell +sudo systemctl restart containerd +``` + kubeadm을 사용하는 경우, -[kubelet용 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 수동으로 구성한다. +[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다. ### CRI-O @@ -453,138 +352,38 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 ### 도커 -각 노드에 도커 CE를 설치한다. +1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다. -쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는 -도커 버전을 찾을 수 있다. +2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다. -사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다. + ```shell + sudo mkdir /etc/docker + cat <}} -{{% tab name="Ubuntu 16.04+" %}} + {{< note >}} + `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. + {{< /note >}} -```shell -# (도커 CE 설치) -## 리포지터리 설정 -### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치 -sudo apt-get update && sudo apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common gnupg2 -``` +3. 도커 재시작과 부팅시 실행되게 설정 -```shell -# 도커 공식 GPG 키 추가: -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - -``` + ```shell + sudo systemctl enable docker + sudo systemctl daemon-reload + sudo systemctl restart docker + ``` -```shell -# 도커 apt 리포지터리 추가: -sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` - -```shell -# 도커 CE 설치 -sudo apt-get update && sudo apt-get install -y \ - containerd.io=1.2.13-2 \ - docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) -``` - -```shell -## /etc/docker 생성 -sudo mkdir /etc/docker -``` - -```shell -# 도커 데몬 설정 -cat <}} - -부팅 시 `docker` 서비스를 시작하려면, 다음 명령을 실행한다. - -```shell -sudo systemctl enable docker -``` - -자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/)를 -참조한다. +{{< note >}} +더 자세한 내용은 + - [도커 데몬 설정](https://docs.docker.com/config/daemon/) + - [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/) +{{< /note >}} diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index dbea03b735..9c241e496f 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -23,7 +23,7 @@ kops는 자동화된 프로비저닝 시스템인데, ## {{% heading "prerequisites" %}} -* [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 반드시 설치해야 한다. +* [kubectl](/ko/docs/tasks/tools/)을 반드시 설치해야 한다. * 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다. @@ -44,7 +44,7 @@ kops는 자동화된 프로비저닝 시스템인데, {{< tabs name="kops_installation" >}} {{% tab name="macOS" %}} -최신 버전의 릴리즈를 다운받는 명령어: +최신 버전의 릴리스를 다운받는 명령어: ```shell curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest @@ -84,7 +84,7 @@ brew update && brew install kops {{% /tab %}} {{% tab name="리눅스" %}} -최신 릴리즈를 다운로드 받는 명령어: +최신 릴리스를 다운로드 받는 명령어: ```shell curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 39f31dd8af..12b48ad17e 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -159,7 +159,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으 높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만, 그 반대의 경우는 아니다. -`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다. +`kubectl` 설치에 대한 정보는 [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 참고한다. {{< warning >}} 이 지침은 모든 시스템 업그레이드에서 모든 쿠버네티스 패키지를 제외한다. @@ -174,16 +174,34 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으 {{< tabs name="k8s_install" >}} {{% tab name="데비안 기반 배포판" %}} -```bash -sudo apt-get update && sudo apt-get install -y apt-transport-https curl -curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - -cat <}} 윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다. @@ -234,7 +234,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다. -#### 컴퓨트 +#### 컴퓨트 {#컴퓨트-제한} ##### 리소스 관리 및 프로세스 격리 @@ -294,7 +294,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 * NFS 기반 스토리지/볼륨 지원 * 마운트된 볼륨 확장(resizefs) -#### 네트워킹 +#### 네트워킹 {#네트워킹-제한} 윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다. diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index 7bcbb39489..8cb17b2ec0 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -1906,7 +1906,7 @@ filename | sha512 hash - Promote SupportNodePidsLimit to GA to provide node to pod pid isolation Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing] - Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling] -- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](https://kubernetes.io/docs/reference/using-api/api-concepts/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing] +- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing] - Set CSIMigrationvSphere feature gates to beta. Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver. diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index b2ea227718..2d44a51b0e 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -193,7 +193,7 @@ func main() { } ``` -애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다. +애플리케이션이 클러스터 내의 파드로 배치된 경우, [파드 내에서 API 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#파드에서-api-접근)을 참고한다. #### Python 클라이언트 {#python-client} diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 272da1e329..487d89379e 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -168,36 +168,7 @@ controllerManager: ### 인증서 서명 요청(CSR) 생성 -`kubeadm certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다. - -[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. -그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. -다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다. - -```shell -sudo kubeadm certs renew apiserver --use-api & -``` -출력 결과는 다음과 비슷하다. -``` -[1] 2890 -[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created -``` - -### 인증서 서명 요청(CSR) 승인 - -외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. - -그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다. - -```shell -kubectl certificate approve kubeadm-cert-kube-apiserver-ld526 -``` -출력 결과는 다음과 비슷하다. -```shell -certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved -``` - -`kubectl get csr` 명령으로 보류 중인 인증서 목록을 볼 수 있다. +쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다. ## 외부 CA로 인증서 갱신 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 26fa2830ff..f7dcbab677 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -16,7 +16,7 @@ weight: 10 ## {{% heading "prerequisites" %}} -[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다. +[`kubectl`](/ko/docs/tasks/tools/)를 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index 28655ed57b..8b4d5afe36 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -12,7 +12,7 @@ weight: 30 ## {{% heading "prerequisites" %}} -[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index 9e4f8de774..678814de3d 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -13,7 +13,7 @@ weight: 40 ## {{% heading "prerequisites" %}} -[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 16b2cd05f0..e420acbed9 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -29,7 +29,7 @@ kubectl apply -k ## {{% heading "prerequisites" %}} -[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. +[`kubectl`](/ko/docs/tasks/tools/)을 설치한다. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md new file mode 100644 index 0000000000..f814db9919 --- /dev/null +++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -0,0 +1,226 @@ +--- +title: 클러스터에서 TLS 인증서 관리 +content_type: task +--- + + + +쿠버네티스는 사용자가 제어하는 ​​인증 기관 (CA)에서 서명한 TLS 인증서를 +프로비저닝 할 수 있는 `certificates.k8s.io` API를 제공한다. +이러한 CA 및 인증서는 워크로드 간의 신뢰 관계를 구성하는 용도로 사용할 수 있다. + +`certificates.k8s.io` API는 [ACME 초안](https://github.com/ietf-wg-acme/acme/)과 +유사한 프로토콜을 사용한다. + +{{< note >}} +`certificates.k8s.io` API를 사용하여 생성된 인증서는 전용 CA로 서명된다. +이러한 목적을 위해 클러스터 루트 CA를 사용하도록 클러스터를 +구성할 수 있지만, 절대 이에 의존해서는 안된다. +해당 인증서가 클러스터 루트 CA에 대해 유효성을 검사한다고 가정하면 안된다. +{{< /note >}} + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 클러스터에서 TLS 신뢰 + +파드로 실행되는 애플리케이션에서 사용자 정의 CA를 신뢰하려면 +일반적으로 몇 가지 추가 애플리케이션 구성이 필요하다. +TLS 클라이언트 또는 서버가 신뢰하는 CA 인증서 목록에 +CA 인증서 번들을 추가해야 한다. +예를 들어 인증서 체인을 파싱하고, 파싱된 인증서를 [`tls.Config`](https://godoc.org/crypto/tls#Config) 구조체의 +`RootCAs` 필드에 추가하여, golang TLS 구성으로 이를 수행할 수 있다. + +CA 인증서를 파드에서 사용할 수 있는 +[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap)으로 +배포할 수 있다. + +## 인증서 요청 + +다음 섹션에서는 DNS를 통해 액세스되는 쿠버네티스 서비스의 +TLS 인증서를 생성하는 방법을 보여준다. + +{{< note >}} +이 튜토리얼에서는 CFSSL을 사용한다. [여기를 클릭](https://blog.cloudflare.com/introducing-cfssl/)하여 Cloudflare의 PKI 및 TLS 툴킷을 자세히 알아본다. +{{< /note >}} + +## CFSSL 다운로드 및 설치 + +이 예제에 사용된 cfssl 도구는 +[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)에서 다운로드 할 수 있다. + +## 인증서 서명 요청 (CSR) 생성 + +다음 명령을 실행하여 개인 키 및 인증서 서명 요청(또는 CSR)을 +생성한다. + +```shell +cat < +Annotations: +CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700 +Requesting User: yourname@example.com +Status: Pending +Subject: + Common Name: my-svc.my-namespace.svc.cluster.local + Serial Number: +Subject Alternative Names: + DNS Names: my-svc.my-namespace.svc.cluster.local + IP Addresses: 192.0.2.24 + 10.0.34.2 +Events: +``` + +## 인증서 서명 요청 승인 받기 + +인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나 +클러스터 관리자에 의해 일회성으로 수행한다. 여기에 +관련된 내용에 대한 자세한 내용은 아래에서 설명한다. + +## 인증서 다운로드 및 사용 + +CSR이 서명되고 승인되면 다음이 표시된다. + +```shell +kubectl get csr +``` + +```none +NAME AGE REQUESTOR CONDITION +my-svc.my-namespace 10m yourname@example.com Approved,Issued +``` + +다음을 실행하여 발급된 인증서를 다운로드하고 `server.crt` 파일에 +저장할 수 있다. + +```shell +kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \ + | base64 --decode > server.crt +``` + +이제 `server.crt` 및 `server-key.pem`을 키페어(keypair)로 사용하여 +HTTPS 서버를 시작할 수 있다. + +## 인증서 서명 요청 승인 + +(적절한 권한이 있는) 쿠버네티스 관리자는 +`kubectl certificate approve` 과 `kubectl certificate deny` +명령을 사용하여 인증서 서명 요청을 수동으로 승인 (또는 거부) 할 수 있다. +그러나 이 API를 많이 사용한다면, +자동화된 인증서 컨트롤러 작성을 고려할 수 있다. + +위와 같이 kubectl을 사용하는 시스템이든 사람이든, 승인자의 역할은 +CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다. + +1. CSR은 CSR에 서명하는 데 사용되는 개인 키를 제어하는 것이다. 이는 + 승인된 대상으로 가장하는 제 3자의 위협을 해결한다. 위의 예에서 + 이 단계는 파드(pod)가 CSR을 생성하는 데 + 사용되는 개인 키를 제어하는지 확인하는 것이다. +2. CSR은 요청된 상황에서 작동할 권한이 있다. 이것은 + 원하지 않는 대상이 클러스터에 합류(join)하는 위협을 + 해결한다. 위의 예에서, 이 단계는 + 파드가 요청된 서비스에 참여할 수 있는지 확인하는 것이다. + +이 두 가지 요구 사항이 충족되는 경우에만, 승인자가 CSR을 승인하고 +그렇지 않으면 CSR을 거부해야 한다. + +## 승인 허가에 대한 경고문 + +CSR을 승인하는 능력은 환경 내에서 누구를 신뢰하는지 결정한다. CSR 승인 +능력은 광범위하거나 가볍게 부여해서는 안된다. 이 권한을 +부여하기 전에 이전 섹션에서 언급한 +요청의 요구 사항과 특정 인증서 발급의 영향을 +완전히 이해해야 한다. + +## 클러스터 관리자를 위한 참고 사항 + +이 가이드에서는 서명자가 인증서 API를 제공하도록 설정되었다고 가정한다. 쿠버네티스 +컨트롤러 관리자는 서명자의 기본 구현을 제공한다. 이를 +활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와 +`--cluster-signing-key-file` 매개 변수를 +컨트롤러 관리자에 전달한다. diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 47c90ec7fd..8c2b3e1aed 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -53,7 +53,7 @@ kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준 {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 도구를 사용하여 쿠버네티스 클러스터를 만들고 관리할 수 있다. 사용자 친화적인 방식으로 최소한의 실행 가능하고 안전한 클러스터를 설정하고 실행하는 데 필요한 작업을 수행한다. -[kubeadm 설치](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다. +[kubeadm 설치](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다. 설치가 끝나면, [클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)이 가능하다. -kubeadm 설치 가이드 보기 +kubeadm 설치 가이드 보기 diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index 0e8a6ac6ee..96ab0a4024 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -20,10 +20,16 @@ card: 다음과 같은 방법으로 리눅스에 kubectl을 설치할 수 있다. -- [리눅스에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-linux) -- [기본 패키지 관리 도구를 사용하여 설치](#install-using-native-package-management) -- [다른 패키지 관리 도구를 사용하여 설치](#install-using-other-package-management) -- [Google Cloud SDK를 사용하여 설치](#install-on-linux-as-part-of-the-google-cloud-sdk) +- [{{% heading "prerequisites" %}}](#시작하기-전에) +- [리눅스에 kubectl 설치](#리눅스에-kubectl-설치) + - [리눅스에서 curl을 사용하여 kubectl 바이너리 설치]{#install-kubectl-binary-with-curl-on-linux} + - [기본 패키지 관리 도구를 사용하여 설치]{#install-using-native-package-management} + - [다른 패키지 관리 도구를 사용하여 설치]{#install-using-other-package-management} + - [Google Cloud SDK를 사용하여 설치]{#install-on-linux-as-part-of-the-google-cloud-sdk} +- [kubectl 구성 확인](#kubectl-구성-확인) +- [선택적 kubectl 구성](#선택적-kubectl-구성) + - [셸 자동 완성 활성화](#셸-자동-완성-활성화) +- [{{% heading "whatsnext" %}}](#다음-내용) ### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-linux} @@ -100,15 +106,38 @@ card: ### 기본 패키지 관리 도구를 사용하여 설치 {#install-using-native-package-management} {{< tabs name="kubectl_install" >}} -{{< tab name="Ubuntu, Debian 또는 HypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - -echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list -sudo apt-get update -sudo apt-get install -y kubectl -{{< /tab >}} +{{% tab name="데비안 기반의 배포판" %}} -{{< tab name="CentOS, RHEL 또는 Fedora" codelang="bash" >}}cat < /etc/yum.repos.d/kubernetes.repo +1. `apt` 패키지 색인을 업데이트하고 쿠버네티스 `apt` 리포지터리를 사용하는 데 필요한 패키지들을 설치한다. + + ```shell + sudo apt-get update + sudo apt-get install -y apt-transport-https ca-certificates curl + ``` + +2. 구글 클라우드 공개 사이닝 키를 다운로드한다. + + ```shell + sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + ``` + +3. 쿠버네티스 `apt` 리포지터리를 추가한다. + + ```shell + echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + ``` + +4. 새 리포지터리의 `apt` 패키지 색인을 업데이트하고 kubectl을 설치한다. + + ```shell + sudo apt-get update + sudo apt-get install -y kubectl + ``` + +{{% /tab %}} + +{{< tab name="레드햇 기반의 배포판" codelang="bash" >}} +cat < /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index b0747f8a1c..1fd37151a6 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -23,7 +23,7 @@ card: - [macOS에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-macos) - [macOS에서 Homebrew를 사용하여 설치](#install-with-homebrew-on-macos) - [macOS에서 Macports를 사용하여 설치](#install-with-macports-on-macos) -- [Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk) +- [macOS에서 Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk) ### macOS에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-macos} @@ -157,4 +157,4 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 ## {{% heading "whatsnext" %}} -{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file +{{< include "included/kubectl-whats-next.md" >}} diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index c28f41a7cc..ae3fce6cb8 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -103,7 +103,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 AppArmor 지원이 포함된 Kubelet (>= v1.4)이면 어떤 전제 조건이 충족되지 않으면 AppArmor와 함께한 파드를 거부한다. 노드 상에 AppArmor 지원 여부는 -노드 준비 조건 메시지를 확인하여(이후 릴리즈에서는 삭제될 것 같지만) 검증할 수 있다. +노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다. ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}' @@ -396,7 +396,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다. AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다. 모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니 전환이 필요할 때에 상세히 설명할 것이다. -최소 두 번의 릴리즈에 대해서는 필드와 어노테이션 모두를 지원할 것이고, +최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고, 그 이후부터는 어노테이션은 명확히 거부된다. ## 프로파일 제작 {#authoring-profiles} diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index 34095ef424..c1b21d1404 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -1,22 +1,23 @@ --- -title: 컨피그 맵을 사용해서 Redis 설정하기 + + + +title: 컨피그맵을 사용해서 Redis 설정하기 content_type: tutorial --- -이 페이지에서는 컨피그 맵을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다. +이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다. ## {{% heading "objectives" %}} -* 다음을 포함하는 `kustomization.yaml` 파일을 생성한다. - * 컨피그 맵 생성자 - * 컨피그 맵을 사용하는 파드 리소스 -* `kubectl apply -k ./`를 실행하여 작업한 디렉터리를 적용한다. -* 구성이 잘 적용되었는지 확인한다. +* Redis 설정값으로 컨피그맵을 생성한다. +* 생성된 컨피그맵을 마운트하고 사용하는 Redis 파드를 생성한다. +* 설정이 잘 적용되었는지 확인한다. @@ -26,91 +27,227 @@ content_type: tutorial {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * 예시는 `kubectl` 1.14 이상 버전에서 동작한다. -* [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다. +* [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다. -## 실세상 예제: 컨피그 맵을 사용해서 Redis 설정하기 +## 실세상 예제: 컨피그맵을 사용해서 Redis 설정하기 -아래의 단계를 통해서 컨피그 맵에 저장된 데이터를 사용해서 Redis 캐시를 설정할 수 있다. +아래 단계를 통해서, 컨피그맵에 저장된 데이터를 사용하는 Redis 캐시를 설정한다. -첫째, `redis-config` 파일에서 컨피그 맵을 포함한 `kustomization.yaml`를 생성한다. - -{{< codenew file="pods/config/redis-config" >}} +우선, 비어 있는 설정으로 컨피그맵을 생성한다. ```shell -curl -OL https://k8s.io/examples/pods/config/redis-config - -cat <./kustomization.yaml -configMapGenerator: -- name: example-redis-config - files: - - redis-config +cat <./example-redis-config.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: example-redis-config +data: + redis-config: "" EOF ``` -`kustomization.yaml`에 파드 리소스 구성을 추가한다. +위에서 생성한 컨피그맵을 Redis 파드 매니페스트와 함께 적용한다. + +```shell +kubectl apply -f example-redis-config.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +``` + +Redis 파드 매니페스트의 내용을 검토하고 다음의 사항을 염두에 둔다. + +* `config` 라는 이름의 볼륨은 `spec.volumes[1]` 에 의해서 생성된다. +* `spec.volumes[1].items[0]` 내부의 `key` 와 `path` 는 `config` 볼륨에 `redis.conf` 라는 파일명으로 지정된 + `example-redis-config` 컨피그맵의 `redis-config` 키를 노출시킨다. +* 그리고 `config` 볼륨은 `spec.containers[0].volumeMounts[1]` 에 의해서 `/redis-master` 에 마운트된다. + +이 내용은 위의 `example-redis-config` 컨피그맵의 `data.redis-config` 내부 데이터를 파드 안에 있는 +`/redis-master/redis.conf` 파일의 내용으로 노출시키는 순효과(net effect)를 낸다. {{< codenew file="pods/config/redis-pod.yaml" >}} -```shell -curl -OL https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml - -cat <>./kustomization.yaml -resources: -- redis-pod.yaml -EOF -``` - -컨피그 맵과 파드 오브젝트를 생성하도록 kustomization 디렉터리를 적용한다. - -```shell -kubectl apply -k . -``` - 생성된 오브젝트를 확인한다. -```shell -> kubectl get -k . -NAME DATA AGE -configmap/example-redis-config-dgh9dg555m 1 52s -NAME READY STATUS RESTARTS AGE -pod/redis 1/1 Running 0 52s +```shell +kubectl get pod/redis configmap/example-redis-config ``` -이 예제에서는 설정 볼륨이 `/redis-master`에 마운트되어 있다. -`redis-config` 키를 `redis.conf`라는 이름의 파일에 추가하기 위해 `path`를 사용한다. -따라서, Redis 설정을 위한 파일 경로는 `/redis-master/redis.conf`이다. -이곳이 이미지가 Redis 마스터를 위한 설정 파일을 찾는 곳이다. +다음의 결과를 볼 수 있다. -설정이 올바르게 적용되었는지 확인하기 위해서, -`kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다. +```shell +NAME READY STATUS RESTARTS AGE +pod/redis 1/1 Running 0 8s + +NAME DATA AGE +configmap/example-redis-config 1 14s +``` + +`example-redis-config` 컨피그맵의 `redis-config` 키를 공란으로 둔 것을 기억하자. + +```shell +kubectl describe configmap/example-redis-config +``` + +`redis-config` 키가 비어 있는 것을 확인할 수 있다. + +```shell +Name: example-redis-config +Namespace: default +Labels: +Annotations: + +Data +==== +redis-config: +``` + +`kubectl exec` 를 사용하여 파드에 접속하고, 현재 설정 확인을 위해서 `redis-cli` 도구를 실행한다. ```shell kubectl exec -it redis -- redis-cli +``` + +`maxmemory` 를 확인한다. + +```shell 127.0.0.1:6379> CONFIG GET maxmemory +``` + +기본값인 0을 볼 수 있을 것이다. + +```shell +1) "maxmemory" +2) "0" +``` + +유사하게, `maxmemory-policy` 를 확인한다. + +```shell +127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +이것도 기본값인 `noeviction` 을 보여줄 것이다. + +```shell +1) "maxmemory-policy" +2) "noeviction" +``` + +이제 `example-redis-config` 컨피그맵에 몇 가지 설정값을 추가해 본다. + +{{< codenew file="pods/config/example-redis-config.yaml" >}} + +갱신된 컨피그맵을 적용한다. + +```shell +kubectl apply -f example-redis-config.yaml +``` + +컨피그맵이 갱신된 것을 확인한다. + +```shell +kubectl describe configmap/example-redis-config +``` + +방금 추가한 설정값을 확인할 수 있을 것이다. + +```shell +Name: example-redis-config +Namespace: default +Labels: +Annotations: + +Data +==== +redis-config: +---- +maxmemory 2mb +maxmemory-policy allkeys-lru +``` + +설정이 적용되었는지 확인하려면, `kubectl exec` 를 통한 `redis-cli` 로 Redis 파드를 다시 확인한다. + +```shell +kubectl exec -it redis -- redis-cli +``` + +`maxmemory` 를 확인한다. + +```shell +127.0.0.1:6379> CONFIG GET maxmemory +``` + +기본값인 0을 볼 수 있을 것이다. + +```shell +1) "maxmemory" +2) "0" +``` + +유사하게, `maxmemory-policy` 도 기본 설정인 `noeviction` 을 보여줄 것이다. + +```shell +127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +위의 명령은 다음을 반환한다. + +```shell +1) "maxmemory-policy" +2) "noeviction" +``` + +파드는 연관된 컨피그맵에서 갱신된 값을 인지하기 위해서 재시작이 필요하므로 +해당 설정값이 변경되지 않은 상태이다. 파드를 삭제하고 다시 생성한다. + +```shell +kubectl delete pod redis +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +``` + +이제 마지막으로 설정값을 다시 확인해 본다. + +```shell +kubectl exec -it redis -- redis-cli +``` + +`maxmemory` 를 확인한다. + +```shell +127.0.0.1:6379> CONFIG GET maxmemory +``` + +이것은 이제 갱신된 값인 2097152를 반환한다. + +```shell 1) "maxmemory" 2) "2097152" +``` + +유사하게, `maxmemory-policy` 도 갱신되어 있다. + +```shell 127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +이것은 원하는 값인 `allkeys-lru` 를 반환한다. + +```shell 1) "maxmemory-policy" 2) "allkeys-lru" ``` -생성된 파드를 삭제한다. +생성된 자원을 삭제하여 작업을 정리한다. + ```shell -kubectl delete pod redis +kubectl delete pod/redis configmap/example-redis-config ``` - - ## {{% heading "whatsnext" %}} -* [컨피그 맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 배우기. - - - - +* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/) 배우기. 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 e44e68df85..aac6298a7a 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -37,7 +37,7 @@ weight: 10
  • ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
  • NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.
  • LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
    • -
  • ExternalName - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 externalName으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 kube-dns 버전 1.7 이상에서 지원 가능하다.
    • +
  • ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.

    • 다른 서비스 타입들에 대한 추가 정보는 소스 IP 이용하기 튜토리얼에서 확인 가능하다. 또한 서비스들로 애플리케이션에 접속하기도 참고해 보자.

    부가적으로, spec에 selector를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. selector 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 type: ExternalName을 이용하겠다고 확고하게 의도하는 경우이다.

    diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 0a420100ce..7b1888a15e 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -270,7 +270,7 @@ kubectl apply -f cassandra-statefulset.yaml 기반하였고 OpenJDK 8을 포함한다. 이 이미지는 아파치 데비안 리포의 표준 카산드라 설치본을 포함한다. -환경변수를 이용하여 `cassandra.yaml`에 삽입된 값을 바꿀 수 있다. +환경 변수를 이용하여 `cassandra.yaml`에 삽입된 값을 바꿀 수 있다. | 환경 변수 | 기본값 | | ------------- |:-------------: | 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 a8a2c0653a..2b8ffff7ff 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 @@ -11,7 +11,7 @@ weight: 10 ## {{% heading "prerequisites" %}} - * [kubectl](/ko/docs/tasks/tools/install-kubectl/)을 설치한다. + * [kubectl](/ko/docs/tasks/tools/)을 설치한다. * Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여 쿠버네티스 클러스터를 생성한다. 이 튜토리얼은 [외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데, diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 24e05ab77f..04230b4f3e 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -1,5 +1,7 @@ --- title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기" + + content_type: tutorial weight: 20 card: @@ -15,8 +17,6 @@ min-kubernetes-server-version: v1.14 * 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/) * 여러 개의 웹 프론트엔드 인스턴스 - - ## {{% heading "objectives" %}} * Mongo 데이터베이스를 시작 @@ -87,6 +87,7 @@ kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.ya ```shell kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` +