[ko] Update outdated files in dev-1.20-ko.8 (p1)
This commit is contained in:
Jihoon Seo
@@ -222,7 +222,7 @@ pod2 1/1 Running 0 36s
|
||||
## 레플리카셋 매니페스트 작성하기
|
||||
|
||||
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
|
||||
레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
|
||||
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
|
||||
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
|
||||
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
|
||||
|
||||
@@ -237,7 +237,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
|
||||
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
|
||||
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
|
||||
|
||||
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
|
||||
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
|
||||
`.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
|
||||
|
||||
### 파드 셀렉터
|
||||
|
||||
@@ -54,7 +54,9 @@ kubectl 명령에서 숏컷으로 사용된다.
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
replicationcontroller/nginx created
|
||||
```
|
||||
@@ -64,7 +66,9 @@ replicationcontroller/nginx created
|
||||
```shell
|
||||
kubectl describe replicationcontrollers/nginx
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
Name: nginx
|
||||
Namespace: default
|
||||
@@ -103,14 +107,16 @@ Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
|
||||
echo $pods
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
|
||||
```
|
||||
|
||||
여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
|
||||
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은
|
||||
반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다.
|
||||
다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
|
||||
반환된 목록의 각 파드 이름을 출력하도록 하는 옵션이다.
|
||||
|
||||
|
||||
## 레플리케이션 컨트롤러의 Spec 작성
|
||||
@@ -118,7 +124,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
|
||||
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
|
||||
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
|
||||
환경 설정 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
|
||||
|
||||
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
|
||||
|
||||
@@ -198,7 +204,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
|
||||
|
||||
### 레플리케이션 컨트롤러에서 파드 격리
|
||||
|
||||
파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅, 데이터 복구 등을 위해 서비스에서 파드를 제거하는데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
|
||||
파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
|
||||
|
||||
## 일반적인 사용법 패턴
|
||||
|
||||
@@ -208,8 +214,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
|
||||
|
||||
### 스케일링
|
||||
|
||||
레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
|
||||
레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.
|
||||
레플리케이션컨트롤러는 `replicas` 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다.
|
||||
|
||||
### 롤링 업데이트
|
||||
|
||||
@@ -246,7 +251,6 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
|
||||
|
||||
레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
|
||||
|
||||
|
||||
## API 오브젝트
|
||||
|
||||
레플리케이션 컨트롤러는 쿠버네티스 REST API의 최상위 수준의 리소스이다.
|
||||
@@ -261,8 +265,7 @@ API 오브젝트에 대한 더 자세한 것은
|
||||
이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
|
||||
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
|
||||
|
||||
|
||||
### 디플로이먼트 (권장되는)
|
||||
### 디플로이먼트 (권장됨)
|
||||
|
||||
[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
|
||||
|
||||
|
||||
@@ -313,17 +313,16 @@ myapp-pod 1/1 Running 0 9m
|
||||
파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
|
||||
있다.
|
||||
|
||||
* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
|
||||
Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
|
||||
이미지의 변경은 앱 컨테이너만 재시작시킨다.
|
||||
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
|
||||
* 파드 인프라스트럭처 컨테이너가 재시작된 상황. 이는 일반적인 상황이 아니며 노드에
|
||||
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
|
||||
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
|
||||
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
|
||||
때문에 유실되었다.
|
||||
|
||||
|
||||
|
||||
초기화 컨테이너 이미지가 변경되거나 초기화 컨테이너의 완료 기록이 가비지 수집
|
||||
때문에 유실된 상태이면 파드는 재시작되지 않는다. 이는 쿠버네티스 버전 1.20 이상에
|
||||
적용된다. 이전 버전의 쿠버네티스를 사용하는 경우 해당 쿠버네티스 버전의 문서를
|
||||
참고한다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -312,8 +312,8 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
|
||||
준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로,
|
||||
준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는
|
||||
파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
|
||||
준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는
|
||||
프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
|
||||
파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
|
||||
남아 있다.
|
||||
|
||||
Reference in New Issue
Block a user