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

Update to Outdated files in dev-1.17-ko.6 branch. (#19368) 

* Update to Outdated files in dev-1.17-ko.6 branch.

* Apply suggestions from code review

Co-Authored-By: Seokho Son <shsongist@gmail.com>

Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
Yuk, Yongsu 2020-03-07 14:05:34 +09:00 committed by GitHub
parent 03f13f0fb0
commit ee049c4431
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 103 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/ko/docs/concepts/architecture/nodes.md
View File

@ -184,7 +184,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
#### 안정성
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에)
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제들이 발생했기 때문에)
더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로,
노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터
내 모든 노드를 살핀다.
@ -210,7 +210,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이
`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이
완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
복원될 때까지 모든 축출을 중지하는 것으로 여긴다.

4
content/ko/docs/concepts/configuration/overview.md
View File

@ -28,7 +28,7 @@ weight: 10
- 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다.
## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs}
- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
@ -85,7 +85,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
- `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다.
{{< note >}}
컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다.
{{< /note >}}
{{< note >}}

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

@ -64,6 +64,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
- IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
- Azure 컨테이너 레지스트리(ACR) 사용
- IBM 클라우드 컨테이너 레지스트리 사용
- IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
- 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
- 클러스터 관리자에 의한 노드 구성 필요
@ -85,8 +86,9 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다.
Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을 인증할 것이다.
인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서,
Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여
GCR을 인증할 것이다. 인스턴스의 서비스 계정은
`https://www.googleapis.com/auth/devstorage.read_only`라서,
프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다.
### Amazon Elastic Container Registry 사용
@ -144,12 +146,11 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다.
### IBM 클라우드 컨테이너 레지스트리 사용
IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로,
프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, 레지스트리 네임스페이스에 접근을 승인하는 토큰을 생성할 수 있다.
IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다.
IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started)를 참고한다.
IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started)를 참고한다.
[IBM 클라우드 퍼블릭 이미지](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) 및 사용자의 프라이빗 이미지로부터 컨테이너를 사용자의 IBM 클라우드 쿠버네티스 서비스 클러스터의 `default` 네임스페이스에 디플로이하기 위해서 IBM 클라우드 컨테이너 레지스트리를 사용하면 된다. 컨테이너를 다른 네임스페이스에 디플로이하거나, 다른 IBM 클라우드 컨테이너 레지스트리 지역 또는 IBM 클라우드 계정을 사용하기 위해서는, 쿠버네티스 `imagePullSecret`를 생성한다. 더 자세한 정보는, [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 참고한다.
다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다.
### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
@ -239,6 +240,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
클러스터의 모든 노드가 반드시 동일한 `.docker/config.json`를 가져야 한다. 그렇지 않으면, 파드가
일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스
템플릿은 `.docker/config.json`을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.
@ -362,7 +364,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
- 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다.

33
content/ko/docs/concepts/overview/working-with-objects/names.md
View File

@ -1,5 +1,5 @@
---
title: 이름(Name)
title: 오브젝트 이름과 ID
content_template: templates/concept
weight: 20
---
@ -22,7 +22,35 @@ weight: 20
{{< glossary_definition term_id="name" length="all" >}}
관례에 따라, 쿠버네티스 리소스의 이름은 최대 253자까지 허용되고 소문자 알파벳과 숫자(alphanumeric), `-`, 그리고 `.`로 구성되며 특정 리소스는 보다 구체적인 제약을 갖는다.
다음은 리소스에 일반적으로 사용되는 세가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름들
대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로
DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
- 253자를 넘지 말아야 한다.
- 소문자와 영숫자 `-` 또는 `.` 만 포함한다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### DNS 레이블 이름
일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
정의된 대로 DNS 레이블 표준을 따라야 한다.
이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
- 최대 63자이다.
- 소문자와 영숫자 또는 `-` 만 포함한다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
### 경로 세그먼트 이름
일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수
있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는
"/" 또는 "%"가 포함될 수 없다.
여기 파드의 이름이 `nginx-demo`라는 매니페스트 예시가 있다.
@ -39,6 +67,7 @@ spec:
- containerPort: 80
```
{{< note >}}
일부 리소스 유형은 이름에 추가적인 제약이 있다.
{{< /note >}}

2
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -334,7 +334,7 @@ spec:
{{< note >}}
TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
차이가 있다. 사용자 환경에서의 TLS의 작동 방식을 이해하려면
[nginx](https://git.k8s.io/ingress-nginx/README.md#https),
[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/),
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) 또는 기타
플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다.
{{< /note >}}

11
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -13,9 +13,14 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
{{< note >}}
모든 **크론잡** `일정:` 시간은 잡이 처음 시작된 마스터의 시간대를 기반으로 한다.
{{< /note >}}
{{< caution >}}
모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
의 시간대를 기준으로 한다.
컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를
실행하는 경우 kube-controller-manager 컨테이너의 설정된 시간대는 크론 잡 컨트롤러가
사용하는 시간대로 설정한다.
{{< /caution >}}
크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이
52자 이하인지 확인해야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에

82
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -71,53 +71,50 @@ kubectl describe rs/frontend
출력은 다음과 유사할 것이다.
```shell
Name: frontend
Namespace: default
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Name: frontend
Namespace: default
Selector: tier=frontend
Labels: app=guestbook
tier=frontend
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=guestbook
tier=frontend
Labels: tier=frontend
Containers:
php-redis:
Image: gcr.io/google_samples/gb-frontend:v3
Port: 80/TCP
Requests:
cpu: 100m
memory: 100Mi
Environment:
GET_HOSTS_FROM: dns
Mounts: <none>
Volumes: <none>
Image: gcr.io/google_samples/gb-frontend:v3
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts
```
마지막으로 파드가 올라왔는지 확인할 수 있다.
```shell
kubectl get Pods
kubectl get pods
```
다음과 유사한 파드 정보를 볼 수 있다.
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE
frontend-b2zdv 1/1 Running 0 6m36s
frontend-vcmts 1/1 Running 0 6m36s
frontend-wtsmm 1/1 Running 0 6m36s
```
또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다.
확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다.
```shell
kubectl get pods frontend-9si5l -o yaml
kubectl get pods frontend-b2zdv -o yaml
```
메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
@ -125,11 +122,11 @@ kubectl get pods frontend-9si5l -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: 2019-01-31T17:20:41Z
creationTimestamp: "2020-02-12T07:06:16Z"
generateName: frontend-
labels:
tier: frontend
name: frontend-9si5l
name: frontend-b2zdv
namespace: default
ownerReferences:
- apiVersion: apps/v1
@ -137,7 +134,7 @@ metadata:
controller: true
kind: ReplicaSet
name: frontend
uid: 892a2330-257c-11e9-aecd-025000000001
uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
...
```
@ -166,16 +163,17 @@ kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
파드를 가져온다.
```shell
kubectl get Pods
kubectl get pods
```
결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다.
```shell
NAME READY STATUS RESTARTS AGE
frontend-9si5l 1/1 Running 0 1m
frontend-dnjpy 1/1 Running 0 1m
frontend-qhloh 1/1 Running 0 1m
pod2 0/1 Terminating 0 4s
frontend-b2zdv 1/1 Running 0 10m
frontend-vcmts 1/1 Running 0 10m
frontend-wtsmm 1/1 Running 0 10m
pod1 0/1 Terminating 0 1s
pod2 0/1 Terminating 0 1s
```
파드를 먼저 생성한다.
@ -191,15 +189,15 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가
레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다.
```shell
kubectl get Pods
kubectl get pods
```
다음 출력에서 볼 수 있다.
```shell
NAME READY STATUS RESTARTS AGE
frontend-pxj4r 1/1 Running 0 5s
pod1 1/1 Running 0 13s
pod2 1/1 Running 0 13s
frontend-hmmj2 1/1 Running 0 9s
pod1 1/1 Running 0 36s
pod2 1/1 Running 0 36s
```
이러한 방식으로 레플리카셋은 템플릿을 사용하지 않는 파드를 소유하게 된다.

4
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
View File

@ -33,8 +33,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다.
TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 즉,
의존하는 오브젝트와 함께 삭제한다. 리소스가 삭제되면 완료자(finalizers)와
TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 이는
의존하는 오브젝트도 해당 리소스와 함께 삭제되는 것을 의미한다. 리소스가 삭제되면 완료자(finalizers)와
같은 라이프 사이클 보증이 적용 된다.
TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중

11
content/ko/docs/contribute/participating.md
View File

@ -24,6 +24,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
@ -52,7 +53,8 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 다음 작업을 할 수 있다.
- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기.
- 풀 리퀘스트/ 에 대한 구속력 없는 피드백 제공
- 풀 리퀘스트에 대한 구속력 없는 피드백 제공
- 기존 컨텐츠를 현지화하는데 도움주는 것
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
{{< note >}}
@ -120,7 +122,6 @@ GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하
- 이슈 해결 및 분류
- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성
- 현지화
- 코드에서 사용자 화면 문자열 편집
- 코드 코멘트 개선
@ -166,7 +167,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm
승인자는
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다.
GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다.
승인자는 다음의 작업을 할 수 있다.
@ -225,7 +226,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm
것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
문서를 참고한다.
## SIG Docs chairperson
## SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
@ -297,7 +298,7 @@ PR 소유자에게 조언하는데 활용된다.
- 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
[PR Wrangler](#pr-wrangler) EHsms [SIG Docs 의장](#sig-docs-chairperson)과
[PR Wrangler](#pr-wrangler) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
{{% /capture %}}

4
content/ko/docs/tasks/_index.md
View File

@ -57,10 +57,6 @@ content_template: templates/concept
클러스터를 운영하기 위한 일반적인 태스크를 배운다.
## 페더레이션(federation) 운영하기(administering)
클러스터 페더레이션의 컴포넌트들을 구성한다.
## 스테이트풀 애플리케이션 관리하기
스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.

4
content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
View File

@ -86,7 +86,9 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username=
```
{{< note >}}
`kubectl config unset users.<name>`을 실행하여 사용자를 삭제할 수 있다.
- 사용자를 삭제하려면 `kubectl --kubeconfig=config-demo config unset users.<name>` 를 실행한다.
- 클러스터를 제거하려면 `kubectl --kubeconfig=config-demo config unset clusters.<name>` 를 실행한다.
- 컨텍스트를 제거하려면 `kubectl --kubeconfig=config-demo config unset contexts.<name>` 를 실행한다.
{{< /note >}}
컨텍스트 세부사항들을 구성 파일에 추가한다.

2
content/ko/docs/tutorials/online-training/overview.md
View File

@ -39,8 +39,6 @@ content_template: templates/concept
* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials)