Merge pull request #29998 from kubernetes/dev-1.22-ko.1
[ko] 1st Korean localization work for v1.22
This commit is contained in:
Kubernetes Prow Robot
@@ -21,7 +21,7 @@ weight: 10
|
||||
|
||||
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
|
||||
|
||||
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
|
||||
- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
|
||||
|
||||
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
|
||||
|
||||
@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
||||
|
||||
## 레이블 사용하기
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
|
||||
|
||||
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
|
||||
|
||||
|
||||
@@ -12,26 +12,33 @@ weight: 30
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
|
||||
민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
|
||||
{{< glossary_tooltip term_id="pod" >}} 정의나
|
||||
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
|
||||
내에 그대로 두는 것보다 안전하고 유연하다.
|
||||
자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
|
||||
|
||||
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
|
||||
포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
|
||||
명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
|
||||
일부 시크릿을 만들 수 있다.
|
||||
포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
|
||||
명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
|
||||
포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
|
||||
애플리케이션 코드에 넣을 필요가
|
||||
없음을 뜻한다.
|
||||
|
||||
시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
|
||||
파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
|
||||
노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
|
||||
및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
|
||||
저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
|
||||
|
||||
시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
|
||||
특별히 기밀 데이터를 보관하기 위한 것이다.
|
||||
|
||||
{{< caution >}}
|
||||
쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
|
||||
기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
|
||||
액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
|
||||
시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
|
||||
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
|
||||
또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
|
||||
|
||||
시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
|
||||
|
||||
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
|
||||
2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
|
||||
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
|
||||
활성화 또는 구성.
|
||||
3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
<!-- body -->
|
||||
@@ -47,6 +54,10 @@ weight: 30
|
||||
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
|
||||
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
|
||||
|
||||
쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
|
||||
[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
|
||||
노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
|
||||
|
||||
시크릿 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
|
||||
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
|
||||
API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
|
||||
시크릿을 노출하는 파드를 실행할 수 있다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
|
||||
|
||||
Reference in New Issue
Block a user