Second Korean l10n work for release-1.16 (#16784)
* Update file outdated korean docs in dev-1.16-ko.2. (#16614) * Translate docs/templates/feature-state-*.txt in Korean (#16613) * Translate pod-topology-spread-constraints in Korean (#16654) Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
742880937b
commit
d50f2cdcc9
@@ -78,7 +78,7 @@ kubectl get pods --namespace=<insert-namespace-name-here>
|
||||
```shell
|
||||
kubectl config set-context --current --namespace=<insert-namespace-name-here>
|
||||
# 확인하기
|
||||
kubectl config view | grep namespace:
|
||||
kubectl config view --minify | grep namespace:
|
||||
```
|
||||
|
||||
## 네임스페이스와 DNS
|
||||
|
||||
@@ -230,7 +230,7 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p
|
||||
적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 불가).
|
||||
|
||||
또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
|
||||
기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
|
||||
기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
|
||||
|
||||
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
|
||||
이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
|
||||
|
||||
@@ -161,8 +161,8 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
|
||||
컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다.
|
||||
이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
|
||||
|
||||
활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는,
|
||||
[활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
|
||||
활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는,
|
||||
[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
|
||||
|
||||
## 파드 및 컨테이너 상태
|
||||
|
||||
@@ -398,7 +398,7 @@ spec:
|
||||
[컨테이너 라이프사이클 이벤트에 핸들러 부착하기](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
* Hands-on 경험하기
|
||||
[활성 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
|
||||
[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
|
||||
|
||||
* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
|
||||
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
title: 파드 토폴로지 분배 제약 조건
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 필수 구성 요소
|
||||
|
||||
### 기능 게이트 활성화
|
||||
|
||||
`EvenPodsSpread` 기능 게이트의 활성화가 되었는지 확인한다(기본적으로 1.16에서는
|
||||
비활성화되어있다). 기능 게이트의 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
|
||||
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에
|
||||
대해 `EvenPodsSpread` 기능 게이트가 활성화되어야 한다.
|
||||
|
||||
### 노드 레이블
|
||||
|
||||
토폴로지 분배 제약 조건은 노드 레이블을 의지해서 각 노드가 속한 토폴로지 도메인(들)을 인식한다. 예를 들어, 노드에 다음과 같은 레이블을 가지고 있을 수 있다. `node=node1,zone=us-east-1a,region=us-east-1`
|
||||
|
||||
다음 레이블이 있고, 4개 노드를 가지는 클러스터가 있다고 가정한다.
|
||||
|
||||
```
|
||||
NAME STATUS ROLES AGE VERSION LABELS
|
||||
node1 Ready <none> 4m26s v1.16.0 node=node1,zone=zoneA
|
||||
node2 Ready <none> 3m58s v1.16.0 node=node2,zone=zoneA
|
||||
node3 Ready <none> 3m17s v1.16.0 node=node3,zone=zoneB
|
||||
node4 Ready <none> 2m43s v1.16.0 node=node4,zone=zoneB
|
||||
```
|
||||
|
||||
그러면 클러스터는 논리적으로 다음과 같이 보이게 된다.
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.
|
||||
|
||||
## 파드의 분배 제약 조건
|
||||
|
||||
### API
|
||||
|
||||
`pod.spec.topologySpreadConstraints` 필드는 1.16에서 다음과 같이 도입되었다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: <integer>
|
||||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
```
|
||||
|
||||
사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
|
||||
|
||||
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다.
|
||||
- **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
|
||||
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
|
||||
- `DoNotSchedule` (기본값)은 스케줄러에 스케줄을 하지 말라고 알려준다.
|
||||
- `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선순위를 부여하면서, 스케줄을 계속하도록 지시한다.
|
||||
- **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
|
||||
|
||||
사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다.
|
||||
|
||||
### 예시: 단수 토폴로지 분배 제약 조건
|
||||
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
신규 파드가 기존 파드와 함께 영역에 걸쳐서 균등하게 분배되도록 하려면, 스펙(spec)은 다음과 같이 주어질 수 있다.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
|
||||
|
||||
`topologyKey: zone` 는 "zone:<any value>" 레이블 쌍을 가지는 노드에 대해서만 균등한 분배를 적용하는 것을 의미한다. `whenUnsatisfiable: DoNotSchedule` 은 만약 들어오는 파드가 제약 조건을 만족시키지 못하면 스케줄러에게 pending 상태를 유지하도록 지시한다.
|
||||
|
||||
만약 스케줄러가 이 신규 파드를 "zoneA"에 배치하면 파드 분포는 [3, 1]이 되며, 따라서 실제 차이(skew)는 2 (3 - 1)가 되어 `maxSkew: 1` 를 위반하게 된다. 이 예시에서는 들어오는 파드는 오직 "zoneB"에만 배치할 수 있다.
|
||||
|
||||
```
|
||||
+---------------+---------------+ +---------------+---------------+
|
||||
| zoneA | zoneB | | zoneA | zoneB |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
| P | P | P | P | | P | P | P P | |
|
||||
+-------+-------+-------+-------+ +-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
사용자는 파드 스펙을 조정해서 다음과 같은 다양한 요구사항을 충족할 수 있다.
|
||||
|
||||
- `maxSkew` 를 "2" 보다 큰 값으로 변경해서 들어오는 파드들이 "zoneA"에도 배치할 수 있도록 한다.
|
||||
- `topologyKey` 를 "node"로 변경해서 파드가 영역이 아닌, 노드에 걸쳐 고르게 분산할 수 있게 한다. 위의 예시에서 만약 `maxSkew` 가 "1"로 유지되면 들어오는 파드는 오직 "node4"에만 배치할 수 있다.
|
||||
- `whenUnsatisfiable: DoNotSchedule` 에서 `whenUnsatisfiable: ScheduleAnyway` 로 변경하면 들어오는 파드는 항상 다른 스케줄링 API를 충족한다는 가정하에 스케줄할 수 있도록 보장한다. 그러나 일치하는 파드가 적은 토폴로지 도메인에 배치되는 것이 좋다. (이 선호도는 리소스 사용 비율 등과 같은 다른 내부 스케줄링 우선순위와 공동으로 정규화 된다는 것을 알아두자.)
|
||||
|
||||
### 예시: 다중 토폴로지 분배 제약 조건
|
||||
|
||||
4개 노드를 가지는 클러스터에 `foo:bar` 가 레이블된 3개의 파드가 node1, node2 그리고 node3에 각각 위치한다고 가정한다(`P`는 파드를 나타낸다).
|
||||
|
||||
```
|
||||
+---------------+---------------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 |
|
||||
+-------+-------+-------+-------+
|
||||
| P | P | P | |
|
||||
+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
사용자는 2개의 TopologySpreadConstraints를 사용해서 영역과 노드에 파드를 분배하는 것을 제어할 수 있다.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}
|
||||
|
||||
이 경우에는, 첫번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
|
||||
|
||||
다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+-------+
|
||||
| zoneA | zoneB |
|
||||
+-------+-------+-------+
|
||||
| node1 | node2 | nod3 |
|
||||
+-------+-------+-------+
|
||||
| P P | P | P P |
|
||||
+-------+-------+-------+
|
||||
```
|
||||
|
||||
만약 사용자가 "two-constraints.yaml" 을 이 클러스터에 적용하면, "mypod"가 `Pending` 상태로 유지되는 것을 알게 된다. 이러한 이유는, 첫 번째 제약 조건을 충족하기 위해 "mypod"는 오직 "zoneB"에만 놓을 수 있다. 두 번째 제약 조건에서는 "mypod"는 오직 "node2"에만 놓을 수 있다. 그러면 "zoneB"와 "node2"의 공동 결과는 아무것도 반환되지 않는다.
|
||||
|
||||
이 상황을 극복하기 위해서는 사용자가 `maxSkew` 의 증가 또는 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 제약 조건 중 하나를 수정할 수 있다.
|
||||
|
||||
### 규칙
|
||||
|
||||
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
|
||||
|
||||
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
|
||||
|
||||
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
|
||||
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone"레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
|
||||
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
|
||||
|
||||
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
|
||||
|
||||
- 만약 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity` 가 정의되어 있으면, 일치하지 않는 노드는 무시하게 된다.
|
||||
|
||||
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
|
||||
|
||||
```
|
||||
+---------------+---------------+-------+
|
||||
| zoneA | zoneB | zoneC |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| node1 | node2 | node3 | node4 | node5 |
|
||||
+-------+-------+-------+-------+-------+
|
||||
| P | P | P | | |
|
||||
+-------+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
그리고 알다시피 "zoneC"는 제외해야 한다. 이 경우에, "mypod"가 "zoneC"가 아닌 "zoneB"에 배치되도록 yaml을 다음과 같이 구성할 수 있다. 마찬가지로 `spec.nodeSelector` 도 존중된다.
|
||||
|
||||
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
|
||||
|
||||
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
|
||||
|
||||
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
|
||||
더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다.
|
||||
|
||||
- `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에
|
||||
원하는 수의 파드를 얼마든지 채울 수 있다.
|
||||
- `PodAntiAffinity` 로는, 단일 토폴로지 도메인에
|
||||
단 하나의 파드만 스케줄 될 수 있다.
|
||||
|
||||
"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
|
||||
고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와
|
||||
레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
|
||||
더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation)를 참조한다.
|
||||
|
||||
## 알려진 제한사항
|
||||
|
||||
1.16을 기준으로 이 기능은 알파(Alpha)이며, 몇 가지 알려진 제한사항이 있다.
|
||||
|
||||
- `Deployment` 를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
|
||||
- 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -13,7 +13,9 @@ weight: 80
|
||||
오랜 시간 동안 진행해온 누군가로써,
|
||||
혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로써 기여할 수 있다.
|
||||
|
||||
쿠버네티스 문서 스타일 가이드에 대해 더 많은 정보를 알고 싶다면, [스타일 가이드](/docs/contribute/style/style-guide/)를 참고하자.
|
||||
쿠버네티스 문서 내용과 스타일에
|
||||
대해 더 많은 정보를 알고 싶다면,
|
||||
[문서 스타일 개요](/docs/contribute/style/style/)를 참고하자.
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ kubectl config view
|
||||
# e2e 사용자의 암호를 확인한다
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # 사용자 리스트 조회
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # 사용자 리스트 조회
|
||||
kubectl config get-contexts # 컨텍스트 리스트 출력
|
||||
kubectl config current-context # 현재 컨텍스트 출력
|
||||
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
|
||||
@@ -85,10 +85,10 @@ kubectl config unset users.foo # foo 사용자 삭제
|
||||
, `.yml`, `.json` 이 사용된다.
|
||||
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # 리소스(들) 생성
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
||||
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||
kubectl apply -f ./my-manifest.yaml # 리소스(들) 생성
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
||||
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
|
||||
kubectl explain pods,svc # 파드와 서비스 매니페스트 문서를 조회
|
||||
|
||||
@@ -141,7 +141,7 @@ kubectl get services # 네임스페이스 내 모든
|
||||
kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회
|
||||
kubectl get pods -o wide # 네임스페이스 내 모든 파드의 상세 목록 조회
|
||||
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
|
||||
kubectl get pods --include-uninitialized # 초기화되지 않은 것을 포함하여 네임스페이스 내 모든 파드의 목록 조회
|
||||
kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회
|
||||
kubectl get pod my-pod -o yaml # 파드의 YAML 조회
|
||||
kubectl get pod my-pod -o yaml --export # 클러스터 명세 없이 파드의 YAML 조회
|
||||
|
||||
@@ -149,7 +149,8 @@ kubectl get pod my-pod -o yaml --export # 클러스터 명세 없이 파
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
kubectl get services --sort-by=.metadata.name # Name으로 정렬된 서비스의 목록 조회
|
||||
# Name으로 정렬된 서비스의 목록 조회
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# 재시작 횟수로 정렬된 파드의 목록 조회
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
@@ -178,10 +179,6 @@ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# 모든 파드(또는 레이블을 지원하는 다른 쿠버네티스 오브젝트)의 레이블 조회
|
||||
# 마찬가지로 "jq"를 사용
|
||||
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
|
||||
|
||||
# 혹은 이 명령어를 파드와 연관된 모든 레이블을 조회하는데 사용할 수 있다.
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# 어떤 노드가 준비됐는지 확인
|
||||
|
||||
@@ -49,7 +49,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
|
||||
|
||||
단순한 HTTP 서버인 `echoserver` 이미지를 사용해서 쿠버네티스 디플로이먼트를 만들고 `--port`를 이용해서 8080 포트로 노출해보자.
|
||||
```shell
|
||||
kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
|
||||
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
|
||||
```
|
||||
결과는 다음과 비슷하다.
|
||||
```
|
||||
@@ -57,7 +57,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다.
|
||||
```
|
||||
3. `hello-minikube` 디플로이먼트에 액세스하기 위해, 서비스로 노출시킨다.
|
||||
```shell
|
||||
kubectl expose deployment hello-minikube --type=NodePort
|
||||
kubectl expose deployment hello-minikube --type=NodePort --port=8080
|
||||
```
|
||||
`--type=NodePort` 옵션은 서비스 타입을 지정한다.
|
||||
|
||||
|
||||
@@ -31,7 +31,8 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-b
|
||||
|
||||
## 대시보드 UI 접근
|
||||
|
||||
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user) 가이드를 따른다.
|
||||
|
||||
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) 가이드를 따른다.
|
||||
|
||||
{{< warning >}}
|
||||
시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 100
|
||||
|
||||
Horizontal Pod Autoscaler는
|
||||
CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
|
||||
레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다.
|
||||
레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다.
|
||||
|
||||
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
|
||||
|
||||
|
||||
@@ -98,7 +98,8 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
|
||||
Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다.
|
||||
|
||||
```shell
|
||||
sudo install minikube /usr/local/bin
|
||||
sudo mkdir -p /usr/local/bin/
|
||||
sudo install minikube /usr/local/bin/
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
이 기능은 현재 *알파(alpha)* 상태로, 다음을 의미한다.
|
||||
|
||||
* 버전 이름에는 알파(예: v1alpha1)가 포함되어 있다.
|
||||
* 버그가 있을 수 있다. 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다.
|
||||
* 기능 지원은 예고 없이 언제든지 중단될 수 있다.
|
||||
* API는 이후 소프트웨어 릴리즈에서 예고 없이 호환되지 않는 방식으로 변경될 수 있다.
|
||||
* 버그에 의한 위험 증가와 장기적인 지원 부족으로, 단기 테스트 클러스터에서만 사용할 것을 권장한다.
|
||||
|
||||
+7
-7
@@ -1,8 +1,8 @@
|
||||
This feature is currently in a *beta* state, meaning:
|
||||
이 기능은 현재 *베타(beta)* 상태로, 다음을 의미한다.
|
||||
|
||||
* The version names contain beta (e.g. v2beta3).
|
||||
* Code is well tested. Enabling the feature is considered safe. Enabled by default.
|
||||
* Support for the overall feature will not be dropped, though details may change.
|
||||
* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
|
||||
* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
|
||||
* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.**
|
||||
* 버전 이름에는 베타(예: v2beta3)가 포함된다.
|
||||
* 코드의 테스트가 완료 되었다. 기능을 활성화 해도 안전한 것으로 간주된다. 기본으로 활성화 되어 있다.
|
||||
* 자세한 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다.
|
||||
* 오브젝트의 스키마 및(또는) 의미(semantics)는 후속 베타 또는 안정적인 릴리즈에서 호환되지 않는 방식으로 변경될 수 있다. 이 경우, 다음 버전으로 마이그레이션하기 위한 지침을 제공할 것이다. 이를 위해서는 API 오브젝트의 삭제, 수정 또는 재생성이 필요할 수 있다. 편집 과정에서 약간의 생각이 필요할 수 있다. 이 기능을 사용하는 애플리케이션은 가동 중지 시간(downtime)이 필요할 수 있다.
|
||||
* 후속 릴리즈에서 호환되지 않는 변경 가능성이 있으므로 오직 업무상 중요하지 않은 용도로만 권장한다. 만약 사용자가 독립적으로 업그레이드가 가능한 다중 클러스터를 가지고 있다면, 이 제약은 완화될 수 있다.
|
||||
* **베타 기능을 사용해보고, 우리에게 피드백을 주십시오! 베타가 종료된 후에 많은 것을 변경하는 것은 타당하지 않을 수 있습니다.**
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
|
||||
이 기능은 *사용중단(deprecated)* 상태이다. 이 상태에 대한 더 많은 정보는 [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/deprecation-policy/)을 참조한다.
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
이 기능은 *안정적(stable)* 이며, 다음을 의미한다.
|
||||
|
||||
* 버전 이름은 vX 로 표시되며 여기서 X는 정수를 의미한다.
|
||||
* 여러 후속 버전으로 릴리스되는 소프트웨어에서는 안정적인 버전의 기능들이 나타날 것이다.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
labels:
|
||||
foo: bar
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
foo: bar
|
||||
affinity:
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: zone
|
||||
operator: NotIn
|
||||
values:
|
||||
- zoneC
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
@@ -0,0 +1,17 @@
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
labels:
|
||||
foo: bar
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
foo: bar
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
@@ -0,0 +1,23 @@
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod
|
||||
labels:
|
||||
foo: bar
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: zone
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
foo: bar
|
||||
- maxSkew: 1
|
||||
topologyKey: node
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
labelSelector:
|
||||
matchLabels:
|
||||
foo: bar
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
Reference in New Issue
Block a user