Fifth Korean l10n work for release-1.16 (#17745)
* Update files outdated Korean docs in dev-1.16-ko.5 (#17537) * Update Korean glossary (#17619) * Translate services-networking/endpoint-slices.md in Korean (#17631) Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <gochist@gmail.com> Co-Authored-By: Wook-Jin, Lee <minjin00@gmail.com> Co-Authored-By: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
0e54ed2d37
commit
4a1fc7f34e
@@ -55,7 +55,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
|
||||
한다([파드 셀렉터](#파드-셀렉터)를 본다).
|
||||
|
||||
데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/)는 `Always` 를 가져야 하며,
|
||||
데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며,
|
||||
명시되지 않은 경우 기본으로 `Always`가 된다.
|
||||
|
||||
### 파드 셀렉터
|
||||
|
||||
@@ -82,8 +82,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
|
||||
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. 만약 디플로이먼트가 여전히 생성중이면 다음과 유사하게 출력된다.
|
||||
```shell
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 0 0 0 1s
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 0/3 0 0 1s
|
||||
```
|
||||
클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다.
|
||||
|
||||
@@ -104,8 +104,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
|
||||
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다. 다음과 유사하게 출력된다.
|
||||
```shell
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 18s
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3/3 3 3 18s
|
||||
```
|
||||
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
|
||||
|
||||
@@ -159,7 +159,7 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
또는 간단하게 다음의 명령어를 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record
|
||||
```
|
||||
|
||||
이와 유사하게 출력된다.
|
||||
@@ -198,8 +198,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
|
||||
* 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다.
|
||||
이와 유사하게 출력된다.
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 36s
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3/3 3 3 36s
|
||||
```
|
||||
|
||||
* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고,
|
||||
@@ -439,7 +439,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
|
||||
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
|
||||
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
|
||||
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
|
||||
@@ -533,8 +533,8 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
|
||||
|
||||
이와 유사하게 출력된다.
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3 3 3 3 30m
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3/3 3 3 30m
|
||||
```
|
||||
3. 디플로이먼트의 설명 가져오기.
|
||||
```shell
|
||||
|
||||
@@ -39,7 +39,7 @@ _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레
|
||||
단일 노드에서 개별 프로세스를 감시하는 대신 레플리케이션 컨트롤러는
|
||||
여러 노드에서 여러 파드를 감시한다.
|
||||
|
||||
레플리케이션 컨트롤러는 디스커션에서 종종 "rc" 혹은 "rcs"로 축약되며
|
||||
레플리케이션 컨트롤러는 디스커션에서 종종 "rc"로 축약되며
|
||||
kubectl 명령에서 숏컷으로 사용된다.
|
||||
|
||||
간단한 경우는 하나의 레플리케이션 컨트롤러 오브젝트를 생성하여
|
||||
|
||||
@@ -260,6 +260,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
|
||||
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
|
||||
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
|
||||
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -60,7 +60,6 @@ weight: 40
|
||||
* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함할 수 있다.
|
||||
예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서
|
||||
다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다.
|
||||
* 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티를 안전하게 실행할 수 있다.
|
||||
* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
|
||||
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
|
||||
* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
|
||||
@@ -69,6 +68,9 @@ weight: 40
|
||||
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
|
||||
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
|
||||
충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다.
|
||||
* 초기화 컨테이너는 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티 혹은 커스텀 코드를 안전하게
|
||||
실행할 수 있다. 불필요한 툴들을 분리한 채로 유지함으로써 앱 컨테이너 이미지의 공격에 대한
|
||||
노출을 제한할 수 있다.
|
||||
|
||||
|
||||
### 예제
|
||||
@@ -124,31 +126,6 @@ spec:
|
||||
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
|
||||
```
|
||||
|
||||
|
||||
아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: myservice
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9376
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: mydb
|
||||
spec:
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: 9377
|
||||
```
|
||||
|
||||
다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다.
|
||||
|
||||
```shell
|
||||
|
||||
@@ -277,10 +277,11 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는
|
||||
|
||||
## 파드의 일생(lifetime)
|
||||
|
||||
일반적으로, 파드는 누군가 파드를 파괴할 때까지 사라지지 않는다.
|
||||
그것은 주로 사람이나 컨트롤러에 의해서 일어난다.
|
||||
이 법칙에 대한 유일한 예외는 일정 기간(마스터의 `terminated-pod-gc-threshold`에 의해 결정되는)
|
||||
이상 파드의 `phase`가 Succeeded 또는 Failed라서 파드가 만료되고 자동적으로 파괴되는 경우이다.
|
||||
일반적으로, 파드는 사람 혹은 컨트롤러의 프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다.
|
||||
컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서
|
||||
`terminated-pod-gc-threshold`에 의해 결정)를 초과할 때,
|
||||
종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다.
|
||||
이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다.
|
||||
|
||||
세 가지 유형의 컨트롤러를 사용할 수 있다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user