diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 6625fe615a..05b5fd71fe 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -30,17 +30,22 @@ weight: 30 특별히 기밀 데이터를 보관하기 위한 것이다. {{< caution >}} -쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. -또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. +쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. +API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. +또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 +해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. +여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. 시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다. 1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다. -1. 시크릿 읽기 및 쓰기를 제한하는 - [RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다. - 파드 생성 권한을 가진 사람은 암묵적으로 시크릿에 접근할 수 있음에 주의한다. -1. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 - 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다. +1. 시크릿에 대한 최소한의 접근 권한을 지니도록 + [RBAC 규칙을 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/)한다. +1. 특정 컨테이너에서만 시크릿에 접근하도록 한다. +1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다. + +시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은 +[쿠버네티스 시크릿에 관한 좋은 관행](/docs/concepts/security/secrets-good-practices)를 참고한다. {{< /caution >}} @@ -96,9 +101,9 @@ weight: 30 시크릿 생성에는 다음과 같은 방법이 있다. -- [`kubectl` 명령으로 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [환경 설정 파일을 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [kustomize를 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [환경 설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [kustomize 도구 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) #### 시크릿 이름 및 데이터에 대한 제약 사항 {#restriction-names-data} @@ -125,43 +130,20 @@ weight: 30 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여 한 네임스페이스의 시크릿 (또는 다른 리소스) 수를 제한할 수 있다. -### 시크릿 편집하기 +### 시크릿 수정하기 -kubectl을 사용하여 기존 시크릿을 편집할 수 있다. +만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다. +시크릿 수정 방식은 다음과 같다. -```shell -kubectl edit secrets mysecret -``` +* [`kubectl` 사용하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) +* [설정 파일 사용하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) -이렇게 하면 기본으로 설정된 에디터가 열리며, -다음과 같이 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다. +[Kustomize 도구](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로 +시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다. -```yaml -# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고, -# 빈 파일을 저장하면 편집이 취소된다. 이 파일을 저장하는 도중에 오류가 발생하면 -# 관련 오류와 함께 파일이 다시 열릴 것이다. -# -apiVersion: v1 -data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm -kind: Secret -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: { ... } - creationTimestamp: 2020-01-22T18:41:56Z - name: mysecret - namespace: default - resourceVersion: "164619" - uid: cfee02d6-c137-11e5-8d73-42010af00002 -type: Opaque -``` - -위의 예시 매니페스트는 `data`에 `username` 및 `password` 2개의 키를 갖는 시크릿을 정의한다. -매니페스트에서 이 값들은 Base64 문자열이지만, -이 시크릿을 파드에 대해 사용할 때에는 kubelet이 파드와 컨테이너에 _디코드된_ 데이터를 제공한다. - -한 시크릿에 여러 키 및 값을 넣을 수도 있고, 여러 시크릿으로 정의할 수도 있으며, 둘 중 편리한 쪽을 고르면 된다. +시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라, +존재하는 `Secret` 오브젝트에 대한 수정은 해당 데이터를 사용하는 파드들에 자동으로 전파된다. +자세한 정보는 [마운트된 시크릿의 자동 업데이트](#마운트된-시크릿의-자동-업데이트)를 참고하라. ### 시크릿 사용하기 @@ -202,9 +184,14 @@ kubelet은 또한 시크릿을 가져올 수 없는 문제에 대한 세부 정 이렇게 구성하려면, 다음을 수행한다. 1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다. -1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. -1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. -1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다. +1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, + 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. +1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. + 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 + `.spec.containers[].volumeMounts[].readOnly = true`와 + `.spec.containers[].volumeMounts[].mountPath`를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 + 각 키는 `mountPath` 아래의 파일명이 된다. 다음은 볼륨에 `mysecret`이라는 시크릿을 마운트하는 파드의 예시이다. @@ -320,11 +307,10 @@ spec: 시크릿이 `/etc/foo` 에 마운트되고, 시크릿 볼륨 마운트로 생성된 모든 파일의 퍼미션은 `0400` 이다. - {{< note >}} -JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우, -JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다. -`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다). +JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우, +JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다. +`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다). YAML로 작성하는 경우, `defaultMode` 값을 8진수로 표기할 수 있다. {{< /note >}} @@ -369,7 +355,7 @@ cat /etc/foo/password 컨테이너의 프로그램은 필요에 따라 이러한 파일에서 시크릿 데이터를 읽는다. -#### 마운트된 시크릿은 자동으로 업데이트됨 +#### 마운트된 시크릿의 자동 업데이트 볼륨이 시크릿의 데이터를 포함하고 있는 상태에서 시크릿이 업데이트되면, 쿠버네티스는 이를 추적하고 최종적으로 일관된(eventually-consistent) 접근 방식을 사용하여 볼륨 안의 데이터를 업데이트한다. @@ -1186,7 +1172,7 @@ data: - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. -- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 +- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339)를 사용하는 절대 UTC 시간. 선택 사항. - `usage-bootstrap-`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 불리언(boolean) 플래그. @@ -1218,22 +1204,23 @@ stringData: ``` -## 수정 불가능한(immutable) 시크릿 {#secret-immutable} +## 불변(immutable) 시크릿 {#secret-immutable} {{< feature-state for_k8s_version="v1.21" state="stable" >}} -쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _수정 불가능_ 으로 표시할 수 있다. +쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _불변_ 으로 표시할 수 있다. 기존 시크릿 데이터의 변경을 금지시키면 다음과 같은 이점을 가진다. - 잘못된(또는 원치 않은) 업데이트를 차단하여 애플리케이션 중단을 방지 - (수만 개 이상의 시크릿-파드 마운트와 같이 시크릿을 대규모로 사용하는 클러스터의 경우,) - 수정 불가능한 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다. - kubelet은 수정 불가능으로 지정된 시크릿에 대해서는 + 불변 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다. + kubelet은 불변으로 지정된 시크릿에 대해서는 [감시(watch)]를 유지할 필요가 없기 때문이다. -### 시크릿을 수정 불가능으로 지정하기 {#secret-immutable-create} +### 시크릿을 불변으로 지정하기 {#secret-immutable-create} + +다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 불변 시크릿을 만들 수 있다. -다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 수정 불가능한 시크릿을 만들 수 있다. ```yaml apiVersion: v1 kind: Secret @@ -1244,10 +1231,10 @@ data: immutable: true ``` -또한 기존의 수정 가능한 시크릿을 변경하여 수정 불가능한 시크릿으로 바꿀 수도 있다. +또한 기존의 수정 가능한 시크릿을 변경하여 불변 시크릿으로 바꿀 수도 있다. {{< note >}} -시크릿 또는 컨피그맵이 수정 불가능으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_. +시크릿 또는 컨피그맵이 불변으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_. 시크릿을 삭제하고 다시 만드는 것만 가능하다. 기존의 파드는 삭제된 시크릿으로의 마운트 포인트를 유지하기 때문에, 이러한 파드는 재생성하는 것을 추천한다. @@ -1280,61 +1267,14 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한 따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다. {{< warning >}} -노드 상의 높은 권한을 갖는(privileged) 컨테이너는 -해당 노드에 있는 모든 시크릿에 접근할 수 있다. +특정 노드에 대해 `privileged: true`가 설정되어 실행 중인 컨테이너들은 전부 +해당 노드에서 사용 중인 모든 시크릿에 접근할 수 있다. {{< /warning >}} - -### 개발자를 위한 보안 추천 사항 - -- 애플리케이션은 환경 변수 또는 볼륨에서 기밀 정보를 읽은 뒤에 기밀 정보를 계속 보호해야 한다. - 예를 들어, 애플리케이션은 비밀 데이터를 암호화되지 않은 상태로 기록하거나 - 신뢰할 수 없는 당사자에게 전송하지 말아야 한다. -- 파드에 여러 컨테이너가 있고, - 그 중 한 컨테이너만 시크릿에 접근해야 하는 경우, - 다른 컨테이너는 해당 시크릿에 접근할 수 없도록 - 볼륨 마운트 또는 환경 변수 구성을 적절히 정의한다. -- {{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 통해 시크릿을 구성하고, - 이 안에 비밀 데이터가 base64로 인코딩된 경우, - 이 파일을 공유하거나 소스 저장소에 올리면 - 해당 매니페스트를 읽을 수 있는 모든 사람이 이 비밀 정보를 볼 수 있음에 주의한다. - base64 인코딩은 암호화 수단이 _아니기 때문에_, 평문과 마찬가지로 기밀성을 제공하지 않는다. -- 시크릿 API와 통신하는 애플리케이션을 배포할 때, - [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 - [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 - 접근을 제한해야 한다. -- 쿠버네티스 API에서, 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은 매우 강력한 기능이다. - 시크릿 목록 조회를 가능하게 하면 - 클라이언트가 해당 네임스페이스에 있는 모든 시크릿의 값을 검사할 수도 있기 때문에 - 가능한 한 이러한 접근 권한을 주는 것은 피해야 한다. - -### 클러스터 관리자를 위한 보안 추천 사항 - -{{< caution >}} -시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값을 볼 수도 있다. -클러스터 정책에서 사용자가 직접 시크릿을 조회하는 것을 금지했더라도, -동일한 사용자가 시크릿을 노출하는 파드에 접근 권한을 가질 수 있다. -{{< /caution >}} - -- (쿠버네티스 API를 사용하여) 클러스터의 모든 시크릿을 감시(`watch`) 또는 나열(`list`)하는 권한을 제한하여, - 가장 특권이 있는 시스템 레벨의 컴포넌트에만 이 동작을 허용한다. -- 시크릿 API와 통신하는 애플리케이션을 배포할 때, - [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 - [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 - 접근을 제한해야 한다. -- API 서버에서, (시크릿을 포함한) 오브젝트는 - {{< glossary_tooltip term_id="etcd" >}}에 저장된다. 그러므로 - - 클러스터 관리자만 etcd에 접근할 수 있도록 한다(읽기 전용 접근 포함) - - 시크릿 오브젝트에 대해 - [저장된 데이터 암호화(encryption at rest)](/docs/tasks/administer-cluster/encrypt-data/)를 활성화하여, - 이러한 시크릿의 데이터가 {{< glossary_tooltip term_id="etcd" >}}에 암호화되지 않은 상태로 저장되지 않도록 한다. - - etcd가 동작하던 장기 저장 장치를 더 이상 사용하지 않는다면 - 초기화 또는 파쇄하는 것을 검토한다. - - etcd 인스턴스가 여러 개라면, - etcd 피어 간 통신에 SSL/TLS를 사용하고 있는지 확인한다. - ## {{% heading "whatsnext" %}} +- 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면 + [쿠버네티스 시크릿을 다루는 좋은 관행들](/docs/concepts/security/secrets-good-practices)을 참고하라. - [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index 5d35733a95..9f86172de4 100644 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -6,7 +6,6 @@ description: 런타임 의존성과 함께 애플리케이션을 패키징하는 # - erictune # - thockin content_type: concept -no_list: true --- @@ -18,7 +17,10 @@ no_list: true 컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다. - +쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는 +해당 노드에 할당된 [파드](/docs/concepts/workloads/pods/)를 +구성하는 컨테이너들을 실행한다. +파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다. @@ -29,16 +31,23 @@ no_list: true 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, 그리고 모든 필수 설정에 대한 기본값이 포함된다. -설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 -변경할 수 없다. 컨테이너화된 애플리케이션이 있고 -변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한 -다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다. +컨테이너는 스테이트리스하며 +[불변(immutable)](https://glossary.cncf.io/immutable-infrastructure/)일 것으로 계획되었다. +즉, 이미 실행 중인 컨테이너의 코드를 수정해서는 안된다. +만일 컨테이너화된 애플리케이션에 수정을 가하고 싶다면, +수정 내역을 포함한 새로운 이미지를 빌드하고, +업데이트된 이미지로부터 +컨테이너를 새로 생성하는 것이 올바른 방법이다. ## 컨테이너 런타임 {{< glossary_definition term_id="container-runtime" length="all" >}} -## {{% heading "whatsnext" %}} +일반적으로 클러스터에서 파드의 기본 컨테이너 런타임을 선택하도록 허용할 수 있다. +만일 클러스터에서 복수의 컨테이너 런타임을 사용해야 하는 경우, +파드에 대해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)을 명시함으로써 +쿠버네티스가 특정 컨테이너 런타임으로 +해당 컨테이너들을 실행하도록 설정할 수 있다. -* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 -* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 +또한 런타임클래스을 사용하면 하나의 컨테이너 런타임을 사용하여 복수의 파드들을 +각자 다른 설정으로 실행할 수도 있다. diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index 21d5b3327f..85521e32cb 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -4,7 +4,7 @@ # - thockin title: 컨테이너 라이프사이클 훅(Hook) content_type: concept -weight: 30 +weight: 40 --- diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ad0fa4ec6..95f9a28e58 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -5,6 +5,7 @@ title: 이미지 content_type: concept weight: 10 +hide_summary: true # 섹션의 목차에 별도로 기재 --- @@ -19,6 +20,12 @@ weight: 10 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. +{{< note >}} +(v{{< skew latestVersion >}}와 같은 최신 마이너 릴리즈와 같은) +쿠버네티스 릴리즈에 대한 컨테이너 이미지를 찾고 있다면 +[쿠버네티스 다운로드](https://kubernetes.io/releases/download/)를 확인하라. +{{< /note >}} + ## 이미지 이름 @@ -149,9 +156,16 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 ## 이미지 인덱스가 있는 다중 아키텍처 이미지 -바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 +[컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 +제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 +[이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. +아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. +그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. -쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. +쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, +접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 +또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. ## 프라이빗 레지스트리 사용 @@ -160,6 +174,9 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 + - Kubelet 자격증명 제공자(Credential Provider)를 통해 프라이빗 레지스트리로부터 동적으로 자격증명을 가져오기 + - kubelet은 특정 프라이빗 레지스트리에 대해 자격증명 제공자 실행 + 플러그인(credential provider exec plugin)을 사용하도록 설정될 수 있다. - 미리 내려받은(pre-pulled) 이미지 - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 @@ -180,6 +197,18 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성 [프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다. 해당 예시는 도커 허브에서 제공하는 프라이빗 레지스트리를 사용한다. +### 인증된 이미지를 가져오기 위한 Kubelet 자격증명 제공자(Credential Provider) {#kubelet-credential-provider} + +{{< note >}} +해당 방식은 kubelet이 자격증명을 동적으로 가져와야 할 때 특히 적절하다. +가장 일반적으로 클라우드 제공자로부터 제공받은 레지스트리에 대해 사용된다. 인증 토큰의 수명이 짧기 때문이다. +{{< /note >}} + +kubelet에서 플러그인 바이너리를 호출하여 컨테이너 이미지에 대한 레지스트리 자격증명을 동적으로 가져오도록 설정할 수 있다. +이는 프라이빗 레지스트리에서 자격증명을 가져오는 방법 중 가장 강력하며 휘발성이 있는 방식이지만, 활성화하기 위해 kubelet 수준의 구성이 필요하다. + +자세한 내용은 [kubelet 이미지 자격증명 제공자 설정하기](/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다. + ### config.json 파일 해석 {#config-json} `config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 28a1e10fe7..81c26e133c 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -4,7 +4,8 @@ # - dchen1107 title: 런타임클래스(RuntimeClass) content_type: concept -weight: 20 +weight: 30 +hide_summary: true # 섹션의 목차에 별도로 기재 ---