kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[ko] Update outdated files in dev-1.26.-ko.1 [M18-22]

pull/40988/head
Jeong Jinwoo 2023-05-25 21:19:33 +09:00
parent 9230a47e60
commit 4135336c73
5 changed files with 103 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
content/ko/docs/concepts/configuration/secret.md
View File

@ -30,17 +30,22 @@ weight: 30
특별히 기밀 데이터를 보관하기 위한 것이다. 특별히 기밀 데이터를 보관하기 위한 것이다.
{{< caution >}} {{< caution >}}
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. 쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나
해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다.
여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다. 시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다. 1. 시크릿에 대해 [저장된 데이터 암호화(Encryption at Rest)를 활성화](/docs/tasks/administer-cluster/encrypt-data/)한다.
1. 시크릿 읽기 및 쓰기를 제한하는 1. 시크릿에 대한 최소한의 접근 권한을 지니도록
[RBAC 규칙을 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/)한다. [RBAC 규칙을 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/)한다.
파드 생성 권한을 가진 사람은 암묵적으로 시크릿에 접근할 수 있음에 주의한다. 1. 특정 컨테이너에서만 시크릿에 접근하도록 한다.
1. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 1. [외부 시크릿 저장소 제공 서비스를 사용하는 것을 고려](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver)한다.
기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인은
[쿠버네티스 시크릿에 관한 좋은 관행](/docs/concepts/security/secrets-good-practices)를 참고한다.
{{< /caution >}} {{< /caution >}}
@ -96,9 +101,9 @@ weight: 30
시크릿 생성에는 다음과 같은 방법이 있다. 시크릿 생성에는 다음과 같은 방법이 있다.
- [`kubectl` 명령으로 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - [`kubectl` 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [환경 설정 파일을 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/) - [환경 설정 파일 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/) - [kustomize 도구 사용하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
#### 시크릿 이름 및 데이터에 대한 제약 사항 {#restriction-names-data} #### 시크릿 이름 및 데이터에 대한 제약 사항 {#restriction-names-data}
@ -125,43 +130,20 @@ weight: 30
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여
한 네임스페이스의 시크릿 (또는 다른 리소스) 수를 제한할 수 있다. 한 네임스페이스의 시크릿 (또는 다른 리소스) 수를 제한할 수 있다.
### 시크릿 편집하기 ### 시크릿 수정하기
kubectl을 사용하여 기존 시크릿을 편집할 수 있다. 만들어진 시크릿은 [불변(immutable)](#secret-immutable)만 아니라면 수정될 수 있다.
시크릿 수정 방식은 다음과 같다.
```shell * [`kubectl` 사용하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret)
kubectl edit secrets mysecret * [설정 파일 사용하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret)
```
이렇게 하면 기본으로 설정된 에디터가 열리며, [Kustomize 도구](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret)로
다음과 같이 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다. 시크릿 내부의 데이터를 수정하는 것도 가능하지만, 이 경우 수정된 데이터를 지닌 새로운 `Secret` 오브젝트가 생성된다.
```yaml 시크릿을 생성한 방법이나 파드에서 시크릿이 어떻게 사용되는지에 따라,
# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고, 존재하는 `Secret` 오브젝트에 대한 수정은 해당 데이터를 사용하는 파드들에 자동으로 전파된다.
# 빈 파일을 저장하면 편집이 취소된다. 이 파일을 저장하는 도중에 오류가 발생하면 자세한 정보는 [마운트된 시크릿의 자동 업데이트](#마운트된-시크릿의-자동-업데이트)를 참고하라.
# 관련 오류와 함께 파일이 다시 열릴 것이다.
#
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이 파드와 컨테이너에 _디코드된_ 데이터를 제공한다.
한 시크릿에 여러 키 및 값을 넣을 수도 있고, 여러 시크릿으로 정의할 수도 있으며, 둘 중 편리한 쪽을 고르면 된다.
### 시크릿 사용하기 ### 시크릿 사용하기
@ -202,9 +184,14 @@ kubelet은 또한 시크릿을 가져올 수 없는 문제에 대한 세부 정
이렇게 구성하려면, 다음을 수행한다. 이렇게 구성하려면, 다음을 수행한다.
1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다. 1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다.
1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다. 1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고,
1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다.
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다. 1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다.
시크릿을 표시하려는 사용되지 않은 디렉터리 이름에
`.spec.containers[].volumeMounts[].readOnly = true`와
`.spec.containers[].volumeMounts[].mountPath`를 지정한다.
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의
각 키는 `mountPath` 아래의 파일명이 된다.
다음은 볼륨에 `mysecret`이라는 시크릿을 마운트하는 파드의 예시이다. 다음은 볼륨에 `mysecret`이라는 시크릿을 마운트하는 파드의 예시이다.
@ -320,11 +307,10 @@ spec:
시크릿이 `/etc/foo` 에 마운트되고, 시크릿이 `/etc/foo` 에 마운트되고,
시크릿 볼륨 마운트로 생성된 모든 파일의 퍼미션은 `0400` 이다. 시크릿 볼륨 마운트로 생성된 모든 파일의 퍼미션은 `0400` 이다.
{{< note >}} {{< note >}}
JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우, JSON을 사용하여 파드 또는 파드 템플릿을 정의하는 경우,
JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다. JSON 스펙은 8진수 표기법을 지원하지 않음에 유의한다.
`defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다). `defaultMode` 값으로 대신 10진수를 사용할 수 있다(예를 들어, 8진수 0400은 10진수로는 256이다).
YAML로 작성하는 경우, `defaultMode` 값을 8진수로 표기할 수 있다. YAML로 작성하는 경우, `defaultMode` 값을 8진수로 표기할 수 있다.
{{< /note >}} {{< /note >}}
@ -369,7 +355,7 @@ cat /etc/foo/password
컨테이너의 프로그램은 필요에 따라 컨테이너의 프로그램은 필요에 따라
이러한 파일에서 시크릿 데이터를 읽는다. 이러한 파일에서 시크릿 데이터를 읽는다.
#### 마운트된 시크릿은 자동으로 업데이트됨 #### 마운트된 시크릿의 자동 업데이트
볼륨이 시크릿의 데이터를 포함하고 있는 상태에서 시크릿이 업데이트되면, 쿠버네티스는 이를 추적하고 볼륨이 시크릿의 데이터를 포함하고 있는 상태에서 시크릿이 업데이트되면, 쿠버네티스는 이를 추적하고
최종적으로 일관된(eventually-consistent) 접근 방식을 사용하여 볼륨 안의 데이터를 업데이트한다. 최종적으로 일관된(eventually-consistent) 접근 방식을 사용하여 볼륨 안의 데이터를 업데이트한다.
@ -1186,7 +1172,7 @@ data:
- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
문자열. 선택 사항. 문자열. 선택 사항.
- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 - `expiration`: 토큰이 만료되어야 하는 시기를 명시한 [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339)를
사용하는 절대 UTC 시간. 선택 사항. 사용하는 절대 UTC 시간. 선택 사항.
- `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 - `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
불리언(boolean) 플래그. 불리언(boolean) 플래그.
@ -1218,22 +1204,23 @@ stringData:
``` ```
## 수정 불가능한(immutable) 시크릿 {#secret-immutable} ## 불변(immutable) 시크릿 {#secret-immutable}
{{< feature-state for_k8s_version="v1.21" state="stable" >}} {{< feature-state for_k8s_version="v1.21" state="stable" >}}
쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _수정 불가능_ 으로 표시할 수 있다. 쿠버네티스에서 특정 시크릿(및 컨피그맵)을 _불변_ 으로 표시할 수 있다.
기존 시크릿 데이터의 변경을 금지시키면 다음과 같은 이점을 가진다. 기존 시크릿 데이터의 변경을 금지시키면 다음과 같은 이점을 가진다.
- 잘못된(또는 원치 않은) 업데이트를 차단하여 애플리케이션 중단을 방지 - 잘못된(또는 원치 않은) 업데이트를 차단하여 애플리케이션 중단을 방지
- (수만 개 이상의 시크릿-파드 마운트와 같이 시크릿을 대규모로 사용하는 클러스터의 경우,) - (수만 개 이상의 시크릿-파드 마운트와 같이 시크릿을 대규모로 사용하는 클러스터의 경우,)
수정 불가능한 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다. 불변 시크릿으로 전환하면 kube-apiserver의 부하를 크게 줄여 클러스터의 성능을 향상시킬 수 있다.
kubelet은 수정 불가능으로 지정된 시크릿에 대해서는 kubelet은 불변으로 지정된 시크릿에 대해서는
[감시(watch)]를 유지할 필요가 없기 때문이다. [감시(watch)]를 유지할 필요가 없기 때문이다.
### 시크릿을 수정 불가능으로 지정하기 {#secret-immutable-create} ### 시크릿을 불변으로 지정하기 {#secret-immutable-create}
다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 불변 시크릿을 만들 수 있다.
다음과 같이 시크릿의 `immutable` 필드를 `true`로 설정하여 수정 불가능한 시크릿을 만들 수 있다.
```yaml ```yaml
apiVersion: v1 apiVersion: v1
kind: Secret kind: Secret
@ -1244,10 +1231,10 @@ data:
immutable: true immutable: true
``` ```
또한 기존의 수정 가능한 시크릿을 변경하여 수정 불가능한 시크릿으로 바꿀 수도 있다. 또한 기존의 수정 가능한 시크릿을 변경하여 불변 시크릿으로 바꿀 수도 있다.
{{< note >}} {{< note >}}
시크릿 또는 컨피그맵이 수정 불가능으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_. 시크릿 또는 컨피그맵이 불변으로 지정되면, 이 변경을 취소하거나 `data` 필드의 내용을 바꿀 수 _없다_.
시크릿을 삭제하고 다시 만드는 것만 가능하다. 시크릿을 삭제하고 다시 만드는 것만 가능하다.
기존의 파드는 삭제된 시크릿으로의 마운트 포인트를 유지하기 때문에, 기존의 파드는 삭제된 시크릿으로의 마운트 포인트를 유지하기 때문에,
이러한 파드는 재생성하는 것을 추천한다. 이러한 파드는 재생성하는 것을 추천한다.
@ -1280,61 +1267,14 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한
따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다. 따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다.
{{< warning >}} {{< warning >}}
노드 상의 높은 권한을 갖는(privileged) 컨테이너는 특정 노드에 대해 `privileged: true`가 설정되어 실행 중인 컨테이너들은 전부
해당 노드에 있는 모든 시크릿에 접근할 수 있다. 해당 노드에서 사용 중인 모든 시크릿에 접근할 수 있다.
{{< /warning >}} {{< /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" %}} ## {{% heading "whatsnext" %}}
- 시크릿의 보안성을 높이고 관리하는 데에 관한 가이드라인을 원한다면
[쿠버네티스 시크릿을 다루는 좋은 관행들](/docs/concepts/security/secrets-good-practices)을 참고하라.
- [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 - [`kubectl` 을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기 - [구성 파일을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기 - [kustomize를 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기

27
content/ko/docs/concepts/containers/_index.md
View File

@ -6,7 +6,6 @@ description: 런타임 의존성과 함께 애플리케이션을 패키징하는
# - erictune # - erictune
# - thockin # - thockin
content_type: concept content_type: concept
no_list: true
--- ---
<!-- overview --> <!-- overview -->
@ -18,7 +17,10 @@ no_list: true
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. 컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다. 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
쿠버네티스 클러스터에 있는 개별 {{< glossary_tooltip text="node" term_id="node" >}}는
해당 노드에 할당된 [파드](/docs/concepts/workloads/pods/)를
구성하는 컨테이너들을 실행한다.
파드 내부에 컨테이너들은 같은 노드에서 실행될 수 있도록 같은 곳에 위치하고 함께 스케줄된다.
<!-- body --> <!-- body -->
@ -29,16 +31,23 @@ no_list: true
여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
그리고 모든 필수 설정에 대한 기본값이 포함된다. 그리고 모든 필수 설정에 대한 기본값이 포함된다.
설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 컨테이너는 스테이트리스하며
변경할 수 없다. 컨테이너화된 애플리케이션이 있고 [불변(immutable)](https://glossary.cncf.io/immutable-infrastructure/)일 것으로 계획되었다.
변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한 즉, 이미 실행 중인 컨테이너의 코드를 수정해서는 안된다.
다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다. 만일 컨테이너화된 애플리케이션에 수정을 가하고 싶다면,
수정 내역을 포함한 새로운 이미지를 빌드하고,
업데이트된 이미지로부터
컨테이너를 새로 생성하는 것이 올바른 방법이다.
## 컨테이너 런타임 ## 컨테이너 런타임
{{< glossary_definition term_id="container-runtime" length="all" >}} {{< 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/)에 대해 읽어보기 각자 다른 설정으로 실행할 수도 있다.

2
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
View File

@ -4,7 +4,7 @@
# - thockin # - thockin
title: 컨테이너 라이프사이클 훅(Hook) title: 컨테이너 라이프사이클 훅(Hook)
content_type: concept content_type: concept
weight: 30 weight: 40
--- ---
<!-- overview --> <!-- overview -->

33
content/ko/docs/concepts/containers/images.md
View File

@ -5,6 +5,7 @@
title: 이미지 title: 이미지
content_type: concept content_type: concept
weight: 10 weight: 10
hide_summary: true # 섹션의 목차에 별도로 기재
--- ---
<!-- overview --> <!-- overview -->
@ -19,6 +20,12 @@ weight: 10
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
{{< note >}}
(v{{< skew latestVersion >}}와 같은 최신 마이너 릴리즈와 같은)
쿠버네티스 릴리즈에 대한 컨테이너 이미지를 찾고 있다면
[쿠버네티스 다운로드](https://kubernetes.io/releases/download/)를 확인하라.
{{< /note >}}
<!-- body --> <!-- body -->
## 이미지 이름 ## 이미지 이름
@ -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) 이미지 - 미리 내려받은(pre-pulled) 이미지
- 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능 - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
- 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요 - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
@ -180,6 +197,18 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
[프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다. [프라이빗 레지스트리에서 이미지 가져오기](/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 파일 해석 {#config-json}
`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. `config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다.

3
content/ko/docs/concepts/containers/runtime-class.md
View File

@ -4,7 +4,8 @@
# - dchen1107 # - dchen1107
title: 런타임클래스(RuntimeClass) title: 런타임클래스(RuntimeClass)
content_type: concept content_type: concept
weight: 20 weight: 30
hide_summary: true # 섹션의 목차에 별도로 기재
--- ---
<!-- overview --> <!-- overview -->