whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Third Korean l10n work for release-1.19

Browse Source 
- Fix issue with broken links in ko documents (#24190)
- Fix issue with links to already translated ko documents (#24158)
- Translate docs/reference/kubectl/docker-cli-to-kubectl/ into Korean (#24131)
- Translate docs/setup/production-environment/tools/kubespray.md in Korean (#24144)
- Translated titles into korean (#24394)
- DNS subdomain translation corrected (#24393)
- Update ko/docs/concepts/overview/working-with-objects/common-labels/ (#24370)
- Translate tasks/job/coarse-parallel-processing-work-queue in Korean (#24218)
- Update outdated files in the dev-1.19-ko.3 branch (#24151)
- Add missing dot on job.md (#24084)

Co-authored-by: chhanz <han0495@gmail.com>
Co-authored-by: Yuuraa <yoorachoi8937@gmail.com>
Co-authored-by: sushil <sushilktiwari.st@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com>
Co-authored-by: Jonghun Park <jonghun.park.194@gmail.com>
Co-authored-by: Leo <leo.lab001@gmail.com>
This commit is contained in:
June Yi
2020-10-16 09:54:30 +09:00
parent 28980202c1
commit a6566dc277
56 changed files with 1389 additions and 844 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/configuration/configmap.md
+1
View File
@@ -214,6 +214,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
content/ko/docs/concepts/configuration/manage-resources-containers.md
-1
View File
@@ -134,7 +134,6 @@ spec:
containers:
- name: app
image: images.my-company.example/app:v4
env:
resources:
requests:
memory: "64Mi"
content/ko/docs/concepts/configuration/pod-priority-preemption.md
+1 -1
View File
@@ -8,7 +8,7 @@ weight: 70
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는
[파드](/ko/docs/concepts/workloads/pods/)는 _우선순위_ 를 가질 수 있다. 우선순위는
다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우,
스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를
스케줄링할 수 있게 한다.
content/ko/docs/concepts/configuration/secret.md
+19 -392
View File
@@ -35,6 +35,12 @@ weight: 30
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다.
`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로
구성되어야 한다.
### 빌트인 시크릿
#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
@@ -50,401 +56,15 @@ weight: 30
서비스 어카운트 작동 방식에 대한 자세한 내용은
[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.
### 자신만의 시크릿 생성하기
### 시크릿 생성하기
#### `kubectl` 사용하여 시크릿 생성하기
시크릿을 생성하기 위한 몇 가지 옵션이 있다.
시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다.
예를 들어, 데이터베이스 연결 문자열은
사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에
저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다.
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
```shell
# 예제를 위해서 필요한 파일들을 생성한다.
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
```
`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고
API 서버에 오브젝트를 생성한다.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
```shell
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
```
출력 결과는 다음과 비슷하다.
```
secret "db-user-pass" created
```
기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다.
```shell
kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
```
{{< note >}}
`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
```shell
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
```
파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
{{< /note >}}
다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다.
```shell
kubectl get secrets
```
출력 결과는 다음과 비슷하다.
```
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
```
시크릿에 대한 설명을 볼 수 있다.
```shell
kubectl describe secrets/db-user-pass
```
출력 결과는 다음과 비슷하다.
```
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password.txt: 12 bytes
username.txt: 5 bytes
```
{{< note >}}
`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지
않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나,
터미널 로그에 저장되지 않도록 보호하기 위함이다.
{{< /note >}}
시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다.
#### 수동으로 시크릿 생성하기
먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한
다음 해당 오브젝트를 생성할 수도 있다.
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은
두 개의 맵(`data` 와 `stringData`)을
포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데
사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은
문자열로 제공할 수 있다.
예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이
문자열을 base64로 변환한다.
```shell
echo -n 'admin' | base64
```
출력 결과는 다음과 비슷하다.
```
YWRtaW4=
```
```shell
echo -n '1f2d1e2e67df' | base64
```
출력 결과는 다음과 비슷하다.
```
MWYyZDFlMmU2N2Rm
```
다음과 같은 시크릿을 작성한다.
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
```
이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다.
```shell
kubectl apply -f ./secret.yaml
```
출력 결과는 다음과 비슷하다.
```
secret "mysecret" created
```
특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이
필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며,
시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다.
이에 대한 실질적인 예는 애플리케이션 배포 시에
구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의
일부를 채우려는 경우이다.
예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우,
```yaml
apiUrl: "https://my.api.com/api/v1"
username: "user"
password: "password"
```
다음 정의를 사용하여 이를 시크릿에 저장할 수 있다.
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |-
apiUrl: "https://my.api.com/api/v1"
username: {{username}}
password: {{password}}
```
그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로
`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다.
`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을
검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다.
```shell
kubectl get secret mysecret -o yaml
```
출력 결과는 다음과 비슷하다.
```yaml
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
```
`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면,
`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자.
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
```
아래의 시크릿에서 결과는 다음과 같다.
```yaml
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
data:
username: YWRtaW5pc3RyYXRvcg==
```
위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다.
`data` 와 `stringData` 의 키는 영숫자,
'-', '_' 또는 '.'로 구성되어야 한다.
{{< note >}}
시크릿 데이터의 직렬화된 JSON 및 YAML 값은
base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로
생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때,
사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는
`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에
`-w 0` 옵션을 추가 *해야 한다*.
{{< /note >}}
#### 생성기를 통해 시크릿 생성하기
쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한
리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의
`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후,
`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다.
#### 파일을 통해 시크릿 생성하기
./username.txt 와 ./password.txt 파일에서
`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다.
```shell
cat <<EOF >./kustomization.yaml
secretGenerator:
- name: db-user-pass
files:
- username.txt
- password.txt
EOF
```
`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
```shell
kubectl apply -k .
```
출력 결과는 다음과 비슷하다.
```
secret/db-user-pass-96mffmfh4k created
```
시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다.
```shell
kubectl get secrets
```
출력 결과는 다음과 비슷하다.
```
NAME TYPE DATA AGE
db-user-pass-96mffmfh4k Opaque 2 51s
```
시크릿에 대한 설명을 볼 수 있다.
```shell
kubectl describe secrets/db-user-pass-96mffmfh4k
```
출력 결과는 다음과 비슷하다.
```
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password.txt: 12 bytes
username.txt: 5 bytes
```
#### 문자열 리터럴(literals)을 통해 시크릿 생성하기
문자열 리터럴인 `username=admin` 과 `password=secret` 을
`secretGenerator` 에 정의하여 시크릿을 만들 수 있다.
```shell
cat <<EOF >./kustomization.yaml
secretGenerator:
- name: db-user-pass
literals:
- username=admin
- password=secret
EOF
```
`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
```shell
kubectl apply -k .
```
출력 결과는 다음과 비슷하다.
```
secret/db-user-pass-dddghtt9b5 created
```
{{< note >}}
시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를
해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은
데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다.
{{< /note >}}
#### 시크릿 디코딩하기
`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다.
예를 들어, 다음 명령을 실행하여 이전 섹션에서
생성된 시크릿을 볼 수 있다.
```shell
kubectl get secret mysecret -o yaml
```
출력 결과는 다음과 비슷하다.
```yaml
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2016-01-22T18:41:56Z
name: mysecret
namespace: default
resourceVersion: "164619"
uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
```
`password` 필드를 디코딩한다.
```shell
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
```
출력 결과는 다음과 비슷하다.
```
1f2d1e2e67df
```
#### 시크릿 편집하기
### 시크릿 편집하기
기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.
@@ -1273,3 +893,10 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
기능이다.
## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기